테스트 커버리지
테스트를 통해 확인할 수 있는 부분의 비율을 커버리지라고 한다. 보통 코드 커버리지와 분기 커버리지를 지표로 많이 활용한다. 코드 커버리지란 (제품 코드 라인 수 / 전체 라인 수)로 테스트를 통해 얼마나 많이 코드 줄이 실행됐는지를 측정한다. 하지만 코드 커버리지는 아래와 같이 단순 포멧팅에 의해 커버리지가 바뀔 수 있는 등 숫자로 장난칠 수 있는 방법이 많다.
// boolean 인자를 받는 메소드에 true가 주어졌을시
String coverageOne(boolean bool) {
String hi = "hello"; // 실행 됨
if (!bool) // 실행 됨
hi = "bye";
return hi; // 실행 됨
// 코드 커버리지 : 3/4 = 75%
}
String coverageTwo(boolean bool) {
String hi = "hello"; // 실행 됨
if (!bool) hi = "bye"; // 실행 됨
return hi; // 실행 됨
// 코드 커버리지 : 3/3 = 100%
}분기 커버리지는 통과 분기 / 전체 분기 수로 코드 커버리지의 단점을 극복하는 데 어느정도 도움이 된다. 하지만 분기 커버리지가 높다고 테스트 코드의 품질을 보장할 수 있는 것은 아니다. SUT의 모든 가능한 결과(중간 연산 결과 등)를 검증했다는 것을 보장하기 어려울 뿐더러, 외부 코드의 경로까지는 고려하지 못한다.
커버리지는 목표가 아니라 지표다
흔히 커버리지 지표는 좋은 부정 지표이지만 나쁜 긍정 지표라고들 말한다. 수치가 낮다면 문제가 있는 거지만, 높다고 해서 무조건 좋은 테스트라고 할 수는 없다. 나는 환자와 체온을 통한 비유가 가장 와닿았다. 환자의 체온이 40도라면 분명 좋지 않은 상황이다. 어떤 치료와 관리를 통해 36.5도로 돌아온다면 환자의 건강에 대한 지표로 유용하게 활용할 수 있다. 하지만 36.5도가 목표가 되어서 빠르게 체온을 낮추기 위해 에어컨을 쎄게 튼다던가, 얼음을 들이붓는 다던가하는 것은 바람직하지 않을 것이다.
결국 목표는 좋은 테스트
테스트가 없는 프로젝트보다 잘못된 테스트를 포함한 프로젝트가 조금 더 진행을 많이 할 수 있겠지만, 결국엔 머지않아 진척도에 침체기가 온다. 결국 테스트가 없는 프로젝트와 작업 소요 시간 대비 진척도가 크게 다르지 않게 된다. 항상 좋은 테스트만을 테스트 스위트에 남기는 것으로 소프트웨어 프로젝트의 지속 가능한 성장을 위해 노력해야한다.
