Code Coverage with PartCover

I’ve been getting more into Test Driven Development (TDD) recently, so I’ve been building up my unit testing toolset as I go along.  I’ve got the basics covered – the industry-standard NUnit as my testing framework & test runner, and Castle Windsor if I need a bit of IOC, are the main things.

But I’m at the stage now where I know the basics so I’m trying to improve my code and my tests, as because anyone in TDD will tell you, if your tests are no good, they may as well not be there.  So the next obvious step was a code coverage tool.  At the basic end, this is a tool that you use to find out how much of your application code actually gets tested by your unit tests, which can be a useful indicator of where you need more tests – although it doesn’t say whether your tests are any good or not, even if you have 100% coverage.

Open Source Tools

Being Scottish by blood, I’m a bit of a skinflint, so like most of my other tools I wanted something open source, or at least free.  This actually proved more difficult than I first imagined – most of the code coverage tools seem to be commercial, often part of a larger package.  Some also required that you alter your code to use them, by adding attributes or method calls – definitely not something I wanted to do.  The main suitable one I came across was PartCover, an open source project hosted on Source Forge.  Thankfully, it was easy to install and set up, and did everything I wanted.

Using PartCover

There are two ways of running PartCover – a console application, which you would use with your build process to generate coverage information as XML, and a graphical browser, which lets you run the tool as you like and browse the results.  I should point out I haven’t tried the console part, or using the generated XML reports, which you would probably want to do in a larger-scale development environment along with Continuous Integration etc.

Either way, the first thing you have to do is configure the tool – you need to define what executable it will run, any arguments, and any rules you want to define about what assemblies & classes to check (or not):

PartCover Settings

You can see here that I’m running NUnit console – you don’t actually have to use this with unit testing.  If you want, you can just get it to fire up your application, use your app manually, and PartCover will tell you what code was run – which I imagine could come in quite handy in itself in certain situations.  But as I want to analyse my unit test coverage, I get it to run NUnit, and pass in my previously created NUnit project as an argument.

Rules

I also have some rules set up.  You can decide to include and exclude any combination of assemblies and classes using a certain format with wildcards – here I’ve included anything in the ‘ContactsClient’ and ‘ContactsDomain’ assemblies, apart from any classes ending in ‘Tests’ and the ‘ContactsClient.Properties’ class.  It can be useful to exclude things like the UI if you’re not testing that, or maybe some generated code that you can’t test – although you shouldn’t use this to sweep things under the carpet that you just don’t want to face!

Analysis

With that done, just click ‘Start’ and you’re away – NUnit console should spring into life, run all of your tests, and you’ll be presented with the results:

PartCover Browser

As you can see, you get a tree-view style display containing the results of all your assemblies, classes and methods, colour coded as a warning.  But that’s not all!  Select ‘View Coverage details’ as I’ve done here, and you can actually see the lines of code which have been run, and those which have been missed.  In my example above, I’ve tested the normal path through the switch statement, but neglected the error conditions – it’s exactly this type of thing that code coverage tools help you to identify, thus enabling you to improve your tests and your code.

At this point, I feel I have to point out a potential issue:

Warning!  Trying to get 100% test coverage can be addictive!

If you’re anything like me, you may well find yourself spending many an hour trying to chase that elusive last few percent.  This may or may not be a problem depending on your point of view – some people are in favour of aiming for 100% coverage, but some think it’s a waste of time.  I like the point of view from Roy Osherove’s Book, that you should test anything with logic in it – which doesn’t include simple getters/setters, etc.

But 100’s such a nice, round number, and I only need a couple more tests to get there..