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?