NCover and working with Code Coverage tools

I have been reluctant to embrace TDD philosophy in my development. I have spent the last year with a philosophy of adding unit test after coding done with DI techniques. The tests were aimed at the “low hanging fruit” scenarios. These included lower level classes with fewer dependencies and logic centric classes. Dependencies like communications, file I/O, and timing based events were classes that tended to be ignored. Not surprisingly my defects were focused in areas not covered by tests. I did employ a practice of writing at least one unit test for each defect.

Recently, after getting encouragement from management to spend time improving unit tests (in part due to schedule slack), I spent some time working with NCover, one of the leading .NET code coverage tools.

NCover has been simply excellent to work with. I have used NCover 3 complete which, at $479, is pretty pricey. NCover 3 classic is reasonably priced at $199. The features provided by the classic level, suit my current usage fine. The quickstart documentation is emphasized by the UI presentation for new projects. The focused ribbon-based UI made it easy to navigate. I found it to be a nice workflow to move between production code viewed in NCover and test code viewed in Visual Studio. For me, I tend to open many documents in Visual Studio at once, and not having to bounce between test and production code files in Visual Studio helped me be more productive.

I spent some time later working with Visual Studio 2010 Code Coverage (available with Premium or Ultimate editions). I think it important to mention my development environment might well affect my perspective. My machine is modern but lacks a solid state hard drive. Visual Studio does crash or hang more than I would like. Visual Studio is also kinda slow and uses lots of virtual memory. I have never met an Add-In that I didn’t want so, so this could well be affecting my experience. These factors collectively encourage me to favor non-integrated tools. More importantly, my single monitor and 1024x768 display really limits my desire to minimize the number and size of visual studio windows open.

Having given these caveats, I strongly preferred my experience with NCover. First, my above issues with Visual Studio make it feel cramped as it is. Second, debugging MSTest unit tests and obtained code coverage are mutually exclusive. I can have on or other turned on at any given time. Hitting Control-R Control-A to debug into unit test is where my sweet spot for working with tests is. I really don’t like the idea of having to switch settings regularly. Third, NCover’s windows and icons are tightly focused on its core tasks. This has helped make learning NCover really easy. In contrast, Visual Studio leverages its existing code editor, status windows, menus, and icons. Using Visual Studio Ultimate, the code coverage-related options are scattered amidst a plethora of features. Fourth , VS requires instrumenting assemblies whereas NCover doesn’t. Since my assemblies are usually signed, this means the assemblies must be modified and then re-signed for each coverage run.