본 내용은 Unit Testing - 블라디미르 코리코프 도서를 읽고 정리한 내용입니다.
단위 테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다.
이미지 출처 : Unit Testing 책
✅ 테스트가 없는 일반 프로젝트는 처음에는 발목을 잡을 것이 없으므로 빨리 시작할 수 있다. 그러나 시간이 지나면서 점점 더 많은 시간을 들여야 처음에 보여준 것과 같은 정도의 진척을 낼 수 있다.
✅ 프로젝트에 살이 붙고 거대해지면 유지보수 및 신규 기능을 적용할 때 오랜 시간이 걸릴 수 있다.
✅ 지속적인 리팩토링과 정리로 코드를 관리하지 않으면 도미노처럼 코드가 무너지거나 냄새나는 코드가 생성될 가능성이 높다.
테스트를 적용하면 위의 문제들을 해결할 수 있다.
나쁜테스트와 좋은 테스트란 무엇인가? 그리고 어떤 요인으로 판단하는가?
잘못된 테스트가 존재하면 여전히 같은 결과를 낳는다.
✅ 모든 테스트를 작성할 필요는 없다. 일부 테스트는 아주 중요하고 소프트웨어 품질에 매우 많은 기여를 한다.
❗️ 중요한 테스트를 제외한 테스트들은 잘못된 경고 발생 및 회귀 오류를 알아내는데 도움이 되지 않으며, 유지 보수가 어렵고 느리다.
❗️ 프로젝트에 도움이 되는지 여부를 알아보기 힘들고 단위 테스트 작성에만 몰두하게 된다.
✅ 쓸데없는 테스트를 많이 쏟아내면 단위 테스트의 목표를 달성할 수 없다.
테스트의 가치와 유지 비용을 모두 고려해야 한다.
특정 커버리지 지표를 목표로 하는 것은 매우 해롭다.
일반적으로는 커버리지가 높을 수록 좋다. 하지만 간단하지 않은 문제이다. 커버리지가 높다고 좋은 테스트라고 보장하지 못한다.
코드 커버리지 = 제품 코드 라인 수 / 전체 라인 수
❗️ 코드 커버리지는 라인으로 단순 계산하기 때문에 커버리지가 높을 수록 좋은 것이 아니다.
✅ 단순히 if문을 2줄에서 1줄로 줄이기만해도 코드 커버리지는 올라간다.
분기 커버리지 = 통과 분기 / 전체 분기 수
✅ 분기 커버리지는 코드 커버리지의 단점을 극복하는 데 도움이 된다.
❗️ 분기 커버리지 또한 테스트 코드의 품질을 판단할 수 없다.
❗️ 분기 커버리지는 가능한 모든 결과를 검증한다고 보증할 수 없다.
커버리지 지표는 좋은 부정 지표이지만 나쁜 긍정 지표이다.
한마디로, 너무 낮으면(60% 이하) 문제가 있다. 그리고 너무 높으면 그것이 테스트가 잘 진행되고 있다고 판단할 수 없다.
결론은 각 테스트를 따로따로 평가하는 것뿐이다.
성공적인 테스트는 다음과 같은 특성을 가지고 있다.
코드가 변경될 때마다 아무리 작은 것이라도 테스트되어야 한다.
초점은 도메인 모델에 머물러 있어야 한다.
도메인 모델을 코드베이스 중 중요하지 않은 부분과 분리해야 한다. 도메인 모델을 다른 애플리케이션 문제와 분리해야 단위 테스트에 대한 노력을 도메인 모델에만 집중할 수 있다.