인프런 커뮤니티 질문&답변

이건 저도 자주 하는 고민입니다.

테스트가 안 되는 기능은 없도록 하는 게 좋습니다. 그러다보면 같은 코드가 여러 개의 테스트에서 반복적으로 검증되는 경우도 종종 발생합니다. 어느 정도까지는 괜찮은 것 같아요.

이 판단은 개발자의 주관적인 판단력을 가지고 해야 합니다.

모든 코드가 다 테스트 되어야 하는 것도 아닙니다. 너무 명확하고 누구나 쉽게 거의 기계적으로 작성할 수 있는 코드를 테스트를 다 만들면 사실 시간 낭비죠. 그래도 중요하다고 생각하는 코드, 변경이 있을 수 있고, 버그가 발생할 수도 있고, 꼭 검증했으면 좋겠다 싶은 코드부터 테스트 합니다.

API 테스트나 기능 테스트 등을 통하면 여러개의 클래스의 코드를 한번에 다 검증하죠. 그러면 개별적으로는 테스트가 필요하지 않은가라고 하면, 또 그때는 코드를 보면서 정말 중요하다고 생각되는 부분, 또 다른 API에서도 재사용될 수 있고 변경될 수 있다고 생각되는 부분부터 테스트를 만듭니다.

가능하면 Payment와 같이 테스트 만들기 쉽고 수행도 빠른 코드부터 테스트를 작성하는 것이 좋습니다. 하지만 리팩버링 하다보면 가끔은 서비스를 타고 테스트가 됐으니까 하고 넘어가는 경우도 생기긴 하네요.

안녕하세요, 인프런 AI 인턴입니다. 구룩님.

테스트 코드 작성에 대한 고민은 개발자라면 누구나 직면하는 이슈입니다. 여기서 다루신 두 가지 질문에 대해 간략히 설명드리겠습니다.

1. 모든 클래스에 대해 테스트가 필요한가?

일반적으로 테스트는 기능의 유효성을 검증하고, 코드의 안정성을 높이기 위해 작성합니다. 하지만 모든 클래스, 특히 단순하게 다른 클래스나 기능을 단순하게 래핑하는 클래스는 테스트의 필요성이 적을 수도 있습니다. 단순한 래퍼 클래스에 대한 테스트는 그 자체보다는 래핑된 기능이 제대로 동작하는지를 확인하기 위한 것이기 때문에 생략하셔도 될 가능성이 큽니다. 물론, 래퍼 클래스가 복잡하거나 래핑 이외의 별도 로직이 추가된다면 테스트가 필요할 수 있습니다.

2. 중복 테스트 문제

PaymentServiceTest와 PaymentTest의 경우, valid 로직이 이동하면서 Payment 로직 자체에 대한 테스트는 PaymentTest에서 이루어지는 것이 맞습니다. PaymentServiceTest는 서비스 레이어의 기능, 높은 수준의 비즈니스 로직 테스트에 중점을 두어야 합니다. 그러므로, Payment의 valid 로직이 Payment 자체에서 충분히 검증되었다면 서비스 레이어에서는 해당 로직에 대한 중복 테스트보다 Payment의 valid 메서드에 의존하는 기능만을 검증하는 것이 일반적입니다.

결국, 테스트 작성의 목적은 기능이 의도된 대로 작동함을 확신하는 것이며, 테스트의 중복이나 비효율적인 테스트를 피하는 것은 그 과정에서 중요한 고려사항입니다.

추가적으로 아래 관련 게시물을 참조하면 도움 될 것 같습니다:
- 테스트 작성 전략 - 중복 테스트 피하기

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.