[단위 테스트] 01. 단위 테스트의 목표

• 단위 테스트에 시간을 투자할 때는 항상 최대한 이득을 얻도록 노력해야 하며, 테스트에 드는 노력을 가능한 한 줄이고 그에 따르는 이득을 최대화해야 한다.

• 단위 테스트 현황

  • 단위 테스트를 작성해야 하는가? 에서 좋은 단위 테스트를 작성하는 것은 어떤 의미인가?로 고민이 바뀌었다.

단위 테스트 목표

• 좋은 설계는 단위 테스트의 사이드 이펙트
• 단위 테스트는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다.

• 소프트웨어 엔트로피 (무질서도)

  • 시간이 지남에 따라 개발 속도가 빠르게 감소하는 현상
  • 지속적인 정리와 리팩터링 등과 같은 적절한 관리를 하지 않고 방치하면 시스템이 점점 더 복잡해지고 무질서해진다. -> 테스트로 이러한 경향을 뒤집을 수 있다.
  • 지속성과 확장성이 핵심!

좋은 테스트와 좋지 않은 테스트를 가르는 요인

• 테스트의 가치와 유지 비용을 모두 고려해야 한다.
• 높은 유지 보수 비용으로 인해 순가치가 0에 가깝거나 심지어 0보다 작은 테스트를 만들지 않도록 경계해야 한다.
• 지속 가능한 성장을 위해서는 고품질 테스트에만 집중해야 한다.

커버리지 지표에 대해서

• 100% 커버리지라고 해서 반드시 양질의 테스트 스위트라고 보장하지는 않는다.
• 코드 커버리지 : 테스트가 실행한 코드의 라인 수를 알 수 있는 지표
• 분기 커버리지 : 테스트 모드가 그래프로 취할 수 있는 가능한 경로를 모두 표시. 그 중 얼마나 통과했는지를 알 수 있는 지표

• 커버리지 지표에 관한 문제점 -> 커버리지 지표로 테스트가 철저한지 또는 테스트가 충분한지 알 수 없다.

  • 테스트 대상 시스템의 모든 가능한 결과를 검증한다고 보장할 수 없다.

    • 커버리지는 일부 실행된 것만 보장한다.
    • 검증이 없는 테스트는 언제나 통과한다.

  • 외부 라이브러리의 코드 경로를 고려할 수 있는 커버리지 지표는 없다.

    • 내부 로직에 대해서 알 수 없음 -> 테스트에서 모든 예외 상황을 다루는지 확인할 방법이 없다.

• 커버리지 지표는 좋은 부정 지표이지만 나쁜 긍정 지표이다.

  • 커버리지 숫자가 낮으면 문제 징후라 할 수 있지만 높다고 좋은 소프트웨어 품질을 보증하는 것은 아니다.

성공적인 테스트 스위트 만들기

• 테스트 스위트가 얼마나 좋은지 자동으로 확인할 수 없다. 개인 판단에 맡겨야 한다.

• 성공적인 테스트 스위트의 특성

  • 개발 주기에 통합돼 있다.

    • 자동화된 테스트를 할 수 있는 방법은 끊임없이 하는 것 뿐이다. 모든 테스트는 개발 주기에 통합되어야 한다.

  • 코드베이스에서 가장 중요한 부분만을 대상으로 한다.

    • 비즈니스 로직 테스트가 시간 투자 대비 최고의 수익을 낼 수 있다.
    • 도메인 모델에 관심을 더 많이 갖는 것이 좋다.
    • 도메인 모델을 다른 애플리케이션 문제와 분리해야 단위 테스트에 대한 노력을 도메인 모델에만 집중할 수 있다.

  • 최소한의 유지비로 최대의 가치를 끌어낸다.

    • 단위 테스트에서 가장 어려운 부분 -> 최소 유지비로 최대 가치를 달성하는 것
• 단위 테스트와 기반 코드는 서로 얽혀 있으므로 코드베이스에 노력을 많이 기울이지 않으면 가치 있는 테스트를 만들 수 없다.

요약

• 코드는 점점 나빠지는 경향이 있다. 테스트는 이러한 경향을 뒤집을 수 있다. 테스트는 안전망 역할을 하며, 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다.
• 좋은 단위 테스트를 적성하는 것이 중요하다.
• 단위 테스트의 목표는 소프트웨어 프로젝트가 지속적으로 성장하게 하는 것이다.
• 테스트 스위트 내에 가치 있는 테스트만 남기고 나머지는 모두 제거하라.
• 단위 테스트는 좋은 부정 지표이지만 나쁜 긍정 지표이다. 커버리지도 마찬가지!
• 분기 커버리지로 테스트 스위트의 완전성에 대해 더 나은 인사이트를 얻을 수 있지만 테스트 스위트가 충분한지는 알 수 없다.