Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Full Coverage by Tests Driven Development (bis)

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.


This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.