Some say that “it’s little valuable to achieve test coverage over 80%” (or 60% insome cases).From the perspective of quality assurance, maybe it’s true. However, from a lean perspective,100% testcoverage could be even easier to achieve than 80% (and much easier than 60%). Sounds weird? I’llexplain.
The most common argument against “100% coverage” is “Do we really need testtrivial methodssuch as getter/setter?” But it’s a bad question. What really matters is not “do we really needtestthem”, but “do we really needwritethem”. I saw programmers wrote (or even generated) getter/setters without test just because doingso is cheap.But these small pieces of code are waste: not only because you need maintain them, but also becausethey(potentially) break design principles such asLaw of Demeter. Creating trivial methods without test-driven is over production. It’sMUDA.
And the tolerance of code-without-test causesMURA(meaning irregular, uneven or inconsistent). Lower the bar of test coverage to 80% (or even 60%),and you’llend up to solve code-without-test in a bigger batch. It requires more consideration and effort everytime youdoing it, and this effort is not split into every story (or even better, every commit) evenly. You’llneeda concentrated hour (or worse, half day) to write tests for code committed a few days ago.
And as we all know,MUDAandMURAcausesMURI(overburden, unreasonableness or absurdity). When it comes to the last day before your release andsuddenly testcoverage drops under the bar, how possible can you get a concentrated hour to fix it? Isn’t itannoying tobe requested writing some test to fix brokencontinuous integrationwhen you are ready to pack your laptop and go home at 6PM? Are you going to do some serious codereview beforetyping in yet another non-sense test case and commit it?
AllowingMUDAto accumulate causesMURA. MURA plus delivery pressure causesMURI. MURI stops you from improving code quality and causes moreMUDA. Thelower the bar, the worse the case. You can break the chain by eliminating every piece ofcode-without-testcontinuously. Test-driven every piece of code.
Bottom line: although it might be little valuable to tighter test coverage restriction from 80% to100% from aquality assurance point of view, doing so makes your life easier (instead of harder). So, why notdoing it?
