In the discussion following my last post Full Coverage by Tests Driven Development , thanks to relevant questions I had the chance to dig dipper into my thoughts. Let me elaborate a bit.
So basically, if one wishes to cover 100% of a portion of code with test, one typically will spend 20% of the effort to cover 80% of the code and the next 80% of the effort to cover the 20% of the code remained uncovered. This is an occurrence of the well known 80/20 law. The conclusion of this law is usually, spend 20% of your effort to get 80% of the result and forget the 20% remaining result which is hard to get.
Here comes the interesting finding: if it is hard to write test to cover a portion of code, it means that the
semantic of this portion of code is complex and/or is not well coded. Such code represents edge-cases
often neglected by developers, like error treatment or very rare and unlikely cases. All of these advocate that the 20% of code that is hard to cover by tests, is also pretty error-prone. And indeed, in my experience, I often stumble on unexpected issues while struggling to cover the few remaining percents of a portion of code.
So now we have another side of the 80/20 law. 80% of the effort is spent writing tests to cover the 20% of the code remained uncovered, but 80% of the issues and bugs are found during this effort. This is another reason why I found it worth to cover 100% of a portion of code. I exposed some others reasons in the post High Test Coverage Ratio is a good thing, Anyway!, including:
- Using code contract coupled with high coverage ratio leads to
checked correctness. - A bug discovered in tested code is easier to fix.
- High test coverage guides mechanically the developer to potential
flaws in the code. - Code fully covered by test is less subject to code erosion.