Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] 무엇을 테스트해야 할까요? #3

Open
boohyunsik opened this issue Jan 15, 2020 · 2 comments
Open

[Question] 무엇을 테스트해야 할까요? #3

boohyunsik opened this issue Jan 15, 2020 · 2 comments
Labels
question Further information is requested

Comments

@boohyunsik
Copy link

Topic

무엇을 테스트해야 할까요?

Detail

커버리지 100%는 헛된 꿈?
a + b = (a+b) 인 간단한 로직 마저 유닛 테스트를 해야 할까요?
각자의 생각, 질문을 마음껏 적어주셨으면 좋겠습니다 :)

@boohyunsik boohyunsik added the question Further information is requested label Jan 15, 2020
@ttkmw
Copy link

ttkmw commented Jan 16, 2020

저는 아래 두 가지를 테스트해야 한다고 생각합니다.

  1. 인터페이스가 되는 부분.
  2. 핵심 로직

인터페이스가 되는 부분에 대해서는 오프라인에 얘기했고,
핵심 로직에 대해 말씀드리자면,
예를 들어 비즈니스 로직과 관련된 부분들은 꼭 테스트해야 하는 것 같아요.
다만 setter라던가, getter등 로직이 없는 부분은 테스트가 필수는 아니라고 생각합니다.
이렇게 생각하고 나니 로직 중 뭐가 핵심이고, 뭐가 핵심이 아니냐 하는 의문이 생겼는데요.
이것은 도메인마다 다르기 때문에 모든 상황을 아우를 수 있는 기준은 없고, 개발자의 판단에 맡겨야 하는 부분이라고 생각합니다.

부가적으로, 커버리지 100%는 굉장히 좋은지표라고 생각합니다.
다만, 좋은거라고 해서 좋기만한 것이 아니라 트레이드오프가 있을텐데요.

  1. 테스트를 작성하는 데 드는 비용.
  2. 원래 의도와 다르게, 진짜 내 코드가 잘 돌아가는가를 확인하는 테스트가 아니라 커버리지만을 위한 테스트를 작성하게 될 가능성.

이 두 가지가 트레이드오프인 것 같아요. 트레이드오프를 고려하여 커버리지 목표를 정하면 좋지 않을까 합니다.

@joomanzi
Copy link

지금 레퍼런스 자료를 못찾았는데, 예전에 관련 글 읽은 것 중에..

80:20 rule((https://dzone.com/articles/applying-8020-rule-software)을 적용하여
80%의 에러는 20%의 코드에서 나온다. 이런 식으로 설명한 글을 봤었는데 공감한 기억이 있습니다.

코드 작성자가 어디서 에러가 날 수 있는지 당연히 알고 있을 수 있기 때문에
해당 부분에 집중하는게 좋을 것 같습니다.
(테스트 코드도 관리해야하는 코드기 때문에 ㅎㅎ..)

100%는 이상적이긴 하지만 우선순위를 정할 때 이런 근거도 생각할 것 같습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants