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?
黄亮的Blog也太重量级了……
October 17th, 2007
如何对private方法进行单元测试
August 12th, 2007
（有很多人很多次问过我这个问题。以下是标准答案。）
问：如何对私有方法进行单元测试？
答：重点在于，你不应该有任何方法是从一开始设计出来就是private的，因为你的每段程序都应该在单元测试的驱动之下产生，而测试是不可能驱动出 来一个private方法的。那么private方法从哪里来？只能从重构而来。所以答案是：private方法是不需要测试的，因为它是重构的产物，而 重构是不改变程序可观察之行为的。既然行为不改变，测试自然也不需要有任何改变，所以不需要针对private方法建立任何新的测试。
问：但是，如果private方法确实出现问题了怎么办？如果确实希望用测试来弄清一个private方法里面到底发生了什么，该怎么办？
答：如果一个private方法复杂到你不能一眼看清它，那它就太复杂了，你应该把它重构成为一个独立的class，然后针对这个class来建立单元测试。
