만개의 테스트를 작성하지 마라.

서론

• 어떤 코드가 유닛 테스트를 작성할 가치가 있는 코드인지 판별하는 방법에 대해 이야기합니다.
• (어그로 죄송합니다.)

 

가치있는 테스트란?

단순히 테스트가 많이 작성되어 있는 것이 결코 좋은게 아닙니다. 여러분이 만약 프라모델을 조립한다고 가정했을 때, 핵심만 잘 정리된 설명서와 별로 중요하지 않은 내용이 포함되어 있는 설명서 중 어떤 문서가 읽기 편하신가요? 아마도 무조건 전자일겁니다.

테스트 또한 문서이기에 핵심만 명확하게 작성되어 있는 것이 훨씬 좋습니다.

 

테스트의 가치란?

그렇다면 우리가 테스트의 우선순위가 떨어지는 코드에는 무엇이 있을까요? 첫번째로 너무 간단한 로직들도 있을거에요. 굳이 문서를 읽지 않아도 이해할 수 있으니까요. 두번째로는 의존객체가 많은 객체들은 테스트하기에 너무 어려울거에요. 실제 객체를 사용할 수 없어서 Test Double을 고려해야하는 경우도 있을거고 의존하는 객체를 생성할 때 너무 많은 값을 필요로해서 ObjectMother를 필요로도 할거에요. 

그럼 반대로 테스트 우선순위가 높은 코드는 무엇이 있을까요? 바로 도메인 로직, 이해하기 어려운 코드, 지나치게 복잡한 코드들입니다. (도메인 로직에 대해서는 다음 글에서 설명합니다.)

이를 시각화하면 다음과 같습니다.

음.. 도메인로직, 간단한 코드, 의존객체가 많고 간단한 코드는 어떻게 테스트를 작성해야할 지 알거같아요. 그런데 복잡한 코드는 테스트할 가치가 높으면서도 테스트하기 어려운데 어떻게 해야할까요.

이 부분은 기존 설계가 잘못되어 있을 가능성이 높습니다. 아마도 테스트하고자 하는 객체가 너무 많은 책임을 가지고 있을 가능성이 높습니다. (웹 서비스에서는 하나의 서비스에 영속성 로직, 도메인 로직, 비즈니스 로직을 다 때려박아놨을 가능성이 높습니다.)

이런 경우에는 위와 같은 방식으로 도메인 모델이나 알고리즘 혹은 간단한 코드 쪽으로 이동하도록 리팩터링하는 것을 권장합니다.

 

결론

• 단위 테스트 시에는 가성비를 생각해야한다.
• 테스트의 가성비는 도메인에서의 가치와 코드의 복잡도를 보고 판단할 수 있다.

 

추천 글

• 도메인 로직과 비즈니스 로직의 차이를 설명할 수 없다면 아래 글을 읽어보세요!
  [번역] 방금 당신이 작성한 코드는 도메인 로직인가?
• 테스트에 대한 확신과 가지고 싶다면 이 서적을 추천합니다!
  유닛테스트 by 블라디미르 코리코프

---

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.