위에서 말한 주장 중 두 번째를 먼저 봅시다. 어느 곳에서는 테스트 커버리지가 87%보다 낮으면 프로덕션 코드에 반영할 수 없다고도 합니다. 누군가는 TDD 같은 것들을 사용해서 100%의 테스트 커버리지를 갖춰야 한다고도 말하죠. 그런데 Wise man은 이렇게 말합니다.
I expect a high level of coverage. Sometimes managers require one. There's a subtle difference.
만약 커버리지 목표치를 특정한 값으로 정해놓으면, 사람들은 이를 달성하려고 시도할텐데요. 문제는 굉장히 낮은 퀄리티의 테스팅으로도 높은 커버리지를 달성할 수 있다는 것입니다. 진짜 극악의 케이스에서는 AssertionFreeTesting도 있습니다. (마지막 문장을 의역하자면) 단순히 높은 커버리지를 위해 만들어진 낮은 퀄리티의 테스트를 보유하고 있으면, 테스팅에서 중요한 것들을 테스트하는데에 방해가 됩니다.
프로그래밍의 여러 관점에서 테스팅은 신중하게 작성되어야 합니다. TDD는 굉장히 유용하지만, 좋은 테스트를 보장하는 만능 도구는 아닙니다. 만약 테스트를 잘 작성하고 있다면 테스트 커버리지는 80 혹은 90 퍼센트 이상을 가리킬 겁니다. 만약 100%를 달성하고 있다면 누군가는 그들이 뭘 테스트하는 지 생각하지 않고, 커버리지 숫자가 높아지는 테스트를 작성하고 있는 것일 수도 있습니다.
사람들이 커버리지에 집중하는 이유는 당연하게도 테스트를 충분하게 하고 있는지를 알고 싶어서 입니다. 확실히 절반보다 낮은 커버리지는 문제의 신호이긴 합니다. 그러나 높은 커버리지가 반드시 많은 것을 시사하진 않으며, ignorance-promoting dashboards 로 가버리게 됩니다. 테스트의 충분성이라는 것은 커버리지가 답해줄 수 있는것보다 훨씬 복잡한 요소입니다. 만약 아래 두 가지 요소를 따라가고 있따면 충분한 테스트를 하고 있다고 말할 수 있습니다.
테스트가 너무 많다는 것을 느낄 수 있는 신호는 테스트 때문에 속도가 떨어지는 것입니다. 굉장히 간단한 코드 수정으로 인해 테스트가 굉장히 오래 많이 변경되어야 한다면 이건 테스트에 문제가 있다는 신호입니다. 이건 너무 많은 것들을 테스트해서가 아닌 테스트에 중복이 있어 그럴 가능성을 시사합니다.
그렇다면 커버리지 분석이 갖는 가치는 무엇일까요? 코드베이스에서 테스팅이 되지 않는 코드를 찾는 것입니다. 커버리지 분석 도구를 자주 실행하고 테스트되지 않은 코드를 확인하는 것은 그만한 가치가 있습니다.
If a part of your test suite is weak in a way that coverage can detect, it's likely also weak in a way coverage can't detect.