단위 테스트의 목표

Table of contents

더 큰 그림

단위 테스트의 목표

• 지속적인 정리와 리팩터링 등과 같은 적절한 관리가 없으면 시스템은 더 복잡해지고 흐트러진다. 테스트는 안전망 역할을 하며, 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다.
• 좋은 단위 테스트는 개발 속도를 지키면서 침체 단계에 빠지지 않게 한다.
• 테스트 스위트 내에 가치 있는 테스트만 남기고 모두 제거하라
• 커버리지 지표는 좋은 부정 지표이지만 나쁜 긍정 지표다. 커버리지가 낮다는 것은 문제의 징후이지만, 커버리지가 높다고 해서 테스트 스위트의 품질이 높은 것은 아니다.
• 분기 커버리지로 테스트 스위트의 완전성에 대해 더 나은 인사이트를 얻을 수 있지만, 테스트 스위트가 충분한지는 여전히 알 수 없다.
• 성공정인 테스트 스위트는 개발 주기에 통합돼 있고, 코드 베이스 중 가장 중요한 부분만을 대상으로 하며, 최소한의 유지비로 최대의 가치를 끌어낸다.

단위 테스트란 무엇인가

• 단위 테스트는 단일 동작 단위를 검증하고, 빠르게 수행하고, 다른 테스트와 별도로 처리한다.
• 격리문제로 런던파는 테스트 대상 단위를 서로 분리해야한다고 보고 테스트 대상 단위는 코드의 단위, 보통 단일 클래스로 본다. 고전파는 단위가 아니라 단위 테스트를 서로 분리해야 한다고 한다. 테스트 대상 단위를 코드 단위가 아니라 동작 단위로 본다.
• 테스트는 코드 단위가 아니라 동작 단위를 검증해야 한다.
• 통합 테스트는 단위 테스트 기준 중 하나 이상을 충족하지 못하는 테스트다.

단위 테스트 구조

• 모든 단위 테스트는 AAA 패턴(Arrange, Act, Assert)을 따라야 한다. 테스트 내 준비나 실행 또는 검증 구절이 여러 개 있으면, 테스트가 여러 동작 단위를 한 번에 검증한다는 표시다.
• 실행(Act) 구절이 한 줄 이상이면 SUT의 API에 문제가 있다는 뜻이다. 클라이언트가 항상 이러한 작업을 같이 수행해야 하고, 이로 인해 잠재적 모순으로 이어질 수 있다.
• 테스트 픽스처 초기화 코드는 생성자에 두지 말고 팩토리 메서드를 도입해서 재사용하자. 이러한 재사용은 테스트간 결합도를 상당히 낮게 유지하고 가독성을 향상 시킨다.
• 엄격한 테스트 명명 정책을 시행하지말고 비개발자들에게 시나리오를 설명하는 것처럼 각 테스트의 이름을 지정하자. (테스트 메서드 대상 이름 넣지 않기)

개발자에게 도움이 되는 테스트 만들기