I love 100% coverage!

Posted by Patrick Smacchia on June 13, 2009

Last week I wrote a post about non-trivial reasons why 100% coverage is useful anyway.

Yesterday, my quest for 100% coverage saved me one more time from some code written too quickly.

  • Code written too quickly, not 100% covered:

  • Code fixed 100% covered:

I am not sure that a proper code review would have detect this one character bug, human eyes are not trained for that.

Moreover, this code is in a IComparer<T>.Compare(…) method used for sorting. In this condition the bug side-effect could be hardly detected by unit tests and contracts.


This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >I’m not sure what this has to do with 100% code coverage.

    Chad, as I explained in my last post, when 1 or 2 sequence points are not covered in a method despite plenty of tests, it can be the symptom of a problem (bug in this particular case, but more likely dead code that cannot be reachable for some reasons).

  • http://chadmyers.lostechies.com Chad Myers

    I’m not sure what this has to do with 100% code coverage. This should’ve been detected with simple TDD unit tests. Simple TDD does not dictate that you test every property (100%). You should cover 100% of your important business logic.

    If you missed this with basic TDD, then that’s a symptom of a larger problem. The effort to achieve 100% coverage is usually not worth it. It’s like trying to achieve the speed of light: The exponential increase in effort to achieve the last few percentage points of coverage (i.e. 95% -> 100%) is almost never worth it.

  • http://weblogs.asp.net/gunnarpeipman/ Gunnar

    Good catch, Patrick. Code coverage analysis will almost always find some more bugs in code. Considering current example… Noam Gal made the point :) ))

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    haha, Noam you made a point indeed :o )

    Concerning R#, I love it and use the last 4.5 version but this particular point is not detected.

  • Noam Gal

    Just a curious question -
    Why not use
    return ilHashB.CompareTo(ilHashA);

    Is it that much less readable?

  • kilativ

    in addition to previous comment, i am 100% for full coverage :) Just saying resharper helps to catch things before you are done coding.

  • kilativ

    Resharper (or intelliJ in case of Java) picks those things up.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Ann, not in this case.

    To find this particular bug one to test that the sorting was indeed well done. Actually some of my tests tested indirectly the ordering of elements and in this particular case, the buggy sort algo was working well!

    Only the non-100% coverage of the Compare(…) method leaded me to investigate and find this silly mistake.

  • Ann

    Caveat: If you cut and paste your tests too, you still won’t find this one. ‘Expect to see’ bugs take so long to find without tests!