단위 테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다.
부수 효과로 코드베이스에 대해 단위 테스트 작성이 필요하면 일반적으로 더 나은 설계로 이어진다.
프로젝트는 지속적인 정리와 리팩터링 등과 같은 적절한 관리를 하지 않으면 시간이 지나면서 프로젝트의 성장하기 어려워진다.
이러한 문제점을 테스트로 해결 가능하다.
테스트는 안전망 역할을 하며 회귀에 대한 보험을 제공하는 도구라고 할 수 있다.
코드베이스를 지속적으로 검증하는 테스트 없이는 소프트웨어 개발이 쉽게 확장되지 않는다.
테스트는 초반에 노력이 필요하지만 후반에 잘 성장할 수 있도록 장기적으로 보면 그 비용을 메울 수 있다.
단위 테스트의 목표는 지속성과 확장성이 핵심이며 단위 테스트를 통해 장기적으로 개발 속도를 유지할 수 있다.
테스트의 비용 요소는 다음과 같은 다양한 활동에 필요한 시간에 따라 결정된다.
테스트도 역시 코드다 다른 코드와 마찬가지로 단위 테스트도 버그에 취약하고 유지 보수가 필요하다.
지속 가능한 프로젝트 성장을 위해서는 고품질 테스트에만 집중해야 한다.
고품질 테스트만이 남을 만한 테스트 유형이다.
테스트 스위트 품질을 평가하는 데 커버리지가 자주 사용된다.
하지만 테스트 커버리지는 테스트 품질을 효과적으로 측정하는 데 사용될 수 없다.
코드 커버리지가 너무 적을 때는 테스트가 충분치 않다는 좋은 증거이다.
하지만 100% 커버리지라고 해서 반드시 양질의 테스트라고 보장하지는 않는다.
높은 커버리지의 테스트도 품질이 떨어질 수 있다.
테스트가 실행하는 코드 라인 수
코드 커버리지 = 실행 코드 라인 수 / 전체 라인 수
코드가 작을수록 코드 커버리지는 올라간다.
하지만 코드를 작게 해도 테스트 가치나 기반 코드베이스의 유지보수성이 변경되는 것은 아니다.
분기 커버리지 지표는 코드 라인 수 대신 if문과 switch 문과 같은 제어 구조에 중점을 둔다.
분기 커버리지 = 통과 분기 / 전체 분기 수
분기 커버리지로 코드 커버리지보다 더 나은 결과를 얻을 수 있지만 테스트 스위트 품질을 결정하는 데 어떤 커버리지도 의존할 수 없는 이유는 다음과 같다.
코드 경로를 통과하는 것이 아니라 실제로 테스트하려면 단위 테스트에는 반드시 적절한 검증이 있어야 한다.
테스트 대상 시스템이 낸 결과가 정확히 예상하는 결과인지 확인해야 한다.
테스트 결과가 여러 개 있을 수 있다.
따라서 커버리지 지표가 의미가 있으려면 모든 측정 지표를 검증해야 한다.
철저히 검증해도 문제가 있다.
모든 커버리지 지표가 테스트 대상 시스템이 메서드를 호출할 때 외부 라이브러리가 통과하는 코드 경로를 고려하지 않는다는 것이다.
테스트 품질을 결정하기에 커버리지 지표만으로는 충분치 않다.
커버리지 지표를 보는 가장 좋은 방법은 지표 그 자체로 보는 것이지 목표로 여겨서는 안된다.
특정 커버리지 숫자를 목표로 하는 것은 단위 테스트의 목표와 반대되는 그릇된 동기 부여가 된다.
커버리지는 좋은 부정 지표이지만 나쁜 긍정 지표이다.
커버리지가 너무 낮으면 문제가 될 수 있지만 높은 숫자도 별 의미가 없다.
테스트 품질을 평가하는 방법은 각 테스트를 하나씩 따로 평가하는 것 뿐이다.
가장 중요한 부분은 비지니스 로직이 있는 부분이다.
다른 부분은 간략하게 또는 간접적으로 검증하는 것이 좋다.
일반적으로 도메인 모델에 관심을 두는게 좋다.
테스트를 빌드 시스템에 통합하는 것만으로는 충분하지 않으며 도메인 모델에 높은 테스트 커버리지를 유지하는 것도 충분하지 않다.
가치가 유지비를 상회하는 테스트만 유지하는 것이 중요하다.