Back in August of 2007, I was assigned an enhancement request for the .Net sample code to integrate with Google Checkout. The enhancement stated that we only had 31% code coverage and we needed to improve our code coverage to 50%. The tool used to determine this code coverage was NCover.

I started playing around with it and was quickly able to realize what sections of the code had never been tested. We wanted to put more faith into our customers that our implementation was production quality so I spent the next week, after work, refining the unit tests until I obtained almost 70% code coverage.

After using the tool for a few days I realized that there were a few patterns throughout my code: The first one was I was writing code for conditions that never had test cases;

The other one was my overloaded constructors were rarely tested - Why would I test them, they should just work right?

Using the NCoverExplorer tool, I quickly began to notice that my branch coverage was on the weak side. I was able to visually see the exact reason why my code was not fully tested, my unit tests were only accounting for a few of the conditions that the code segment was meant to process.

Once you run NCover against your code, a coverage file is generated containing a large amount of very useful information, including the assemblies, namespaces, class names, the methods of those classes and the sequence points (enterprise version only). All of this information is stored in an xml document that can be reloaded for additional analysis.

One day I was sitting around trying to think of a sample project to build using some of the really cool new C# 3.0 language features and I thought to myself, ‘why not create a way to query the NCover coverage file using Linq’. You have to admit, it would be really cool to be able to find all methods in your application that take in a decimal data type or find all the methods that take a parameter with the name of description.

So I sat down one evening and looked at how I could make the information in the coverage file friendlier to search. I did not want to take the Linq to Xml approach at this time.  I enhanced the output of xsd.exe to support generic lists instead of arrays. Then I visited the coverage data and link up all the parent child data to allow people to file all methods that are contained in a class called “foo” that take in a string as a type.

Imagine being able to search all your code for all methods that are not constructors, and that have at least one parameter of type decimal. This is an example of how that statement would look using Linq To NCover:

CodeCoverage c = CodeCoverage.Load(file);

var retVal = from method in c.Methods
from param in method.Parameters
where method.Name != ".ctor"
&& param.FullType == typeof(decimal).ToString()
orderby method.Name
select method; 

Over the next few days, I will continue to expand this article to include releasing the source code.

As a side note, NCover is such a great tool; I am moving to Greenville, SC next week to begin working for this amazing company.

More to come