Software Quality

March 20, 2010

Code Contracts March 2010 Release improves code coverage

Filed under: Code Contracts — David Allen @ 1:26 pm

In previous releases, if you used code contracts and code coverage, your code coverage might be understated due to distortions in the analysis of the code inserted by the code contracts rewriter.

I tested the new version and it fixes this. So now, code coverage behaves as I expect. If you see partial coverage in some contracts, remember to write automated tests to exercise those alternate paths that cause contract failure.

Get the release at


  1. Good news.
    Can you give an example of how it has improved?

    Comment by Robert A. McCarter — March 21, 2010 @ 2:05 pm

  2. The short answer is, that code coverage with Microsoft code contracts now works the way most people will expect it to work.

    Take the following code
    public void Foo(int deposit)
    Contract.Requires(deposit > 0);
    Balance += deposit;
    In an ideal world, if you don’t write a unit test for this, code coverage shows that you missed several blocks of code. If you write the happy path (deposit > 0), then some of the IL for the contract is executed and that line is shown as partially executed. If you also test the contract failure, then you should show 100% coverage of the body AND the contract.

    In the previous version of Microsoft code contracts, even if you tested both the happy path and the contract failure path, the code coverage tool would claim that you had at least one block of untested code. This was due to some intermediate language that would not get executed that was used for internal purposes that should have been transparent to the normal program. In the newest version, they have discovered a way to mark these lines of code in the debugging file in order to prevent erroneous reports of untested code blocks. Technically, they may not be executed under most normal scenarios, but they are not part of a normal execution path, and the presence of these alleging “missing blocks of code” was causing code coverage metrics to underestimate the code coverage of the code for which the developer was responsible. If you want to see Manuel’s remarks and learn more about it, you can read here:

    Comment by David Allen — March 22, 2010 @ 8:36 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: