Home > Unit Testing > Code Coverage with PartCover

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

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.


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!


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

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..

  1. Derek
    March 9, 2011 at 6:23 pm

    I know this is an ancient post, but if you could post your Working arguments in full, that would be great.

    Most people, when publishing these screenshots, never get the whole line in so you don’t know exactly what they ran.

    • relentless development
      March 9, 2011 at 10:29 pm

      Sure, the ‘working arguments’ in the example here is: “E:\Programming\Google Code\winforms-mvp-example\contactsprototype_unittests.nunit”. That’s an NUnit project with the appropriate test assemblies in it.

  2. Sunil R
    October 26, 2011 at 11:58 pm

    Can I use my own unit test application written to test my actual product binaries..?
    If yes, I’m not able to get PartCover work for me.

    Please see the details below,
    I have my unit test application say — MyUnitTester.exe
    MyUnitTester.exe is written to test — MyProduct.dll (has many classes to be tested)

    now how do I use PartCover get coverage using MyUnitTester.exe?

    After configuring PartCover “Run Target Settings” and I click the “Start” button, it opens “RunTargetTracker” window and remains there forever and will never comeback to the PartCover Browser window.

    PartCover version —

    Please provide me with your inputs.

  3. relentless development
    October 27, 2011 at 7:59 am

    Hi Sunil, can’t say this is something I’ve tried, you’re probably better off asking on the PartCover forum or similar (I believe it’s hosted on SourceForge). However, from the UI, it doesn’t seem to be tied to NUnit, so your approach might work – does your test runner take command line arguments specifying what to test? I guess it would need to, and that you’d have to supply them in the ‘working arguments’ field.

    • Sunil R
      October 27, 2011 at 3:22 pm

      Thanks, I’ll try get some more information from PartCover forum.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: