nCover

Tuesday, June 14, 2005

I didn’t realize until recently that there are two different projects going by the name of nCover – the one on ncover.org and the one on SourceForge.

Both projects are code coverage analyzers. Code coverage tools measure the fraction of code exercised during execution. If an assembly has 100 lines of code, and the execution flow covers 30 of those 100 lines, you have 30% code coverage. I think code coverage tools are a natural sidekick to unit testing tools, because you can see and verify what code is being tested. For pros (and cons), see: “How to Misuse Code Coverage” (PDF) by Brian Marick.

The two NCover projects take different approaches to produce coverage numbers. The nCover project on SourceForge requires a pre-build step to modify .cs files and produce an instrumented version of the code base (the tool makes a backup of the original files, and has the ability to ‘de-instrument’ a file). The tool uses regular expressions to find branching logic and inject the coverage points.

The nCover.org tool using the profiling API to compute coverage. There is no modification to source code or pre-build events. The coverage report is an XML file you can XSLT into just what you want to see. If you like XSLT, that is. I’ve tried hard to avoid XSLT for a long time now, for no good reason.

I’m currently leaning towards the nCover from ncover.org. The profiling API feels less intrusive and has few moving parts compared to regular expression matching and munging of source code files. Unfortunately, I have one assembly the tool refuses to measure, and I can’t figure out why.

What do the cool people use?


Comments
Howard van Rooijen Tuesday, June 14, 2005
I wrote a little how-to guide for NCover (.org version), NCoverBrowser and NCoverViewer:
<br>
<br>http://blogs.conchango.com/howardvanrooijen/articles/304.aspx
<br>
<br>/Howard
Scott Willeke Tuesday, June 14, 2005
We've used ncover.sf.net lots in a continuous build. We were forced to since we were writing code against the VS2005 CTPs and every new version of the CTP would trip up the profilers that were using the profiler API. Ncover.sf.net has no dependency on the .NET CLR version like the other one.
Scott Tuesday, June 14, 2005
That's a good point, Scott. I think I'll download the sf.net one, too and at least give it a try.
Darrell Wednesday, June 15, 2005
Well since you asked what the cool people use, I'll say I use the ncover.org one.
Anil John Monday, June 20, 2005
Thanks! I did not know there were two projects either.. I was doing my usual routine of finding a Java Open source product, putting a &quot;N&quot; in front of it, and attaching it to sourceforge.net :-)
Scott Monday, June 20, 2005
I still have one assembly ncover.ncover.org does not profile - the logs show it cannot load the pdb. I have not had time to troubleshoot, but it's a bit puzzling. The pdb is certainly in the right place. Some point I hope to have time to track the problem down.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!