Why Is 100% Test Coverage Easier To Achieve?
April 17th, 2011
Some say that “it’s little valuable to achieve test coverage over 80%” (or 60% in some cases). From the perspective of quality assurance, maybe it’s true. However, from a lean perspective, 100% test coverage could be even easier to achieve than 80% (and much easier than 60%). Sounds weird? I’ll explain.
The most common argument against “100% coverage” is “Do we really need test trivial methods such as getter/setter?” But it’s a bad question. What really matters is not “do we really need test them”, but “do we really need write them”. I saw programmers wrote (or even generated) getter/setters without test just because doing so is cheap. But these small pieces of code are waste: not only because you need maintain them, but also because they (potentially) break design principles such as Law of Demeter . Creating trivial methods without test-driven is over production. It’s MUDA .
And the tolerance of code-without-test causes MURA (meaning irregular, uneven or inconsistent). Lower the bar of test coverage to 80% (or even 60%), and you’ll end up to solve code-without-test in a bigger batch. It requires more consideration and effort every time you doing it, and this effort is not split into every story (or even better, every commit) evenly. You’ll need a concentrated hour (or worse, half day) to write tests for code committed a few days ago.
And as we all know, MUDA and MURA causes MURI (overburden, unreasonableness or absurdity). When it comes to the last day before your release and suddenly test coverage drops under the bar, how possible can you get a concentrated hour to fix it? Isn’t it annoying to be requested writing some test to fix broken continuous integration when you are ready to pack your laptop and go home at 6PM? Are you going to do some serious code review before typing in yet another non-sense test case and commit it?
Allowing MUDA to accumulate causes MURA. MURA plus delivery pressure causes MURI. MURI stops you from improving code quality and causes more MUDA. The lower the bar, the worse the case. You can break the chain by eliminating every piece of code-without-test continuously. Test-driven every piece of code.
Bottom line: although it might be little valuable to tighter test coverage restriction from 80% to 100% from a quality assurance point of view, doing so makes your life easier (instead of harder). So, why not doing it?
