Writing Unit Tests for Pipeline Components with NCover

I discovered NCover over the weekend and wow, am I a fan!

NCover is a code coverage tool which, to quote the website, “helps you test intelligently by revealing which tests haven’t been written yet.” In laymans terms, NCover graphically shows you which lines of code were not touched during the execution of your unit tests, allowing you to create tests accordingly to achieve 100% code coverage, as shown below:

Pipeline Component Testing

Armed with Tomas Restrepo’s excellent Pipeline Testing library, we can now comprehensively test our Pipeline Components:

1. Develop units tests to test your pipeline and ensure that the tests execute and are successful;

2. Invoke your testing framework from the command line to check that your tests will run correctly in the NCover environment (I’m using NUnit here, but you could also invoke VSTS):

"C:Program FilesNUnit 2.4.8binnunit-console.exe" BizTalkMessageArchivingComponent.Tests.dll

Which should produce the following output on the command line:

3. With our unit tests successfully executing, we can wrap the NUnit invocation in NCover loveliness which will inspect our code coverage while those tests executed:

ncover.console "C:Program FilesNUnit 2.4.8binnunit-console.exe" BizTalkMessageArchivingComponent.Tests.dll //ea Modhul.BizTalk.Pipelines.ArchiveMessages.Attributes.NCoverExcludeCoverage //et "Winterdom.*;BizTalkMessageArchivingComponent.Tests.*"

Producing command-line output similar to the following (notice the NUnit tests running between the ***Program Output*** and ***End Program Output*** text):

NCover has now determined the code coverage based of your unit tests and produces a Coverage.Xml file. This file contains information relating to the code coverage and can be loaded in the NCover.Explorer tool to produce a VS like environment that displays lines of code that were touched and un-touched by your unit tests.

4. Load the NCover.Explorer tool and open the Coverage.Xml file generated above, you will be presented with a screen detailing your code coverage. In the example below, you can see that the PerformImmediateCopy and StreamOnReadEvent methods do not have full code coverage – both have code which was not executed in our unit tests:

Clicking on one of the methods in the tree view loads the offending method, displaying the lines which were not executed by our tests in red; lines that were executed are displayed in blue:

Based on this information, we can now create tests to cater for these exceptions, ensuring we have 100% code coverage.

NCover is an excellent tool and although it isn’t free, I personally think its a must-have for any developers tool-kit.

Advertisements

4 thoughts on “Writing Unit Tests for Pipeline Components with NCover

  1. Thanks, Nick! Just getting back from PDC2008 a few hours ago, we back at the office pounding away at the requests we heard from our users.

    Dan (Technology Apostle_

    —–

    We’ve been working hard to build the next generation of NCover. We’re finally ready to show it off, and we feel confident that you’ll love it as much as we do.

    We’ve reworked how we manage coverage data in NCover, and it has led to performance improvements in many operations, including loading coverage files. It has also finally united the way that NCover and NCoverExplorer work, giving a more fluid experience between the applications. With that unification process finally completed, we were able to drive forward with some new features that we’re excited to tell you about.

    NCover 3 Beta includes Symbol and Branch Point Coverage, but it also has two new metrics – Cyclomatic Complexity and Method Visit Coverage.

    Cyclomatic Complexity describes the number of independent paths through your methods. It’s a great indicator of when you should refactor, and code with a low cyclomatic complexity will help you guarantee that new developers on your teams can get up to speed fairly quickly. You can learn more about Cyclomatic Complexity at Wikipedia.

    While method visit coverage previously existed in NCoverExplorer, it only worked when you had symbol points for a method. With our new implementation you can guarantee that methods with no symbol points, including C# 3 automatic properties, have been tested.

    Our team has been dreaming of letting developers see how their coverage has progressed for quite some time, and in NCover 3 our dream comes true. Recording trends is as easy as using the append to trends (//at) flag in NCover. Once you’ve recorded trends you’ll be able to generate html reports with graphs of how your coverage has changed over time and you’ll also be able to see those trends in NCoverExplorer.

    We hated the way that NCoverExplorer in NCover 2 would close its tree view every time you reload coverage, so we fixed that. Now the tree view dynamically updates itself with your new coverage data and stays open just as it was before the reload. Also, the new NCoverExplorer tree view is able to display branch coverage and cyclomatic complexity in addition to symbol and method visit coverage that it supported in version 2.

    The statistics panel has been improved to show you more statistics. We now include various statistics on whatever item you have selected in the tree view, and if you have trend data loaded we show you a trends graph.

    Trends are available in the html report, too. We’ve got a great graph that works across all major browsers and lets you see just how well your coverage is improving.

    We felt like it was important to help you more strategically attack uncovered code, so we have replaced the old html report index with a new summary report that tells you the top 5 worst coverage offenders in several different categories.

    Since coverage is ultimately about digging in and writing tests for uncovered code blocks, we wanted to give you a way to find the blocks to attack at a glance. That’s why we created the Uncovered Code Report. The Uncovered Code Report shows you your top 25 blocks of uncovered code so that you’ll always have a good place to start improving your coverage.

  2. The problem with the code is your file stream will never close if an exception is thrown.

    You should place that code in a using block, the steam will be closed and the exception block will still be visited (if it is an IOException).

    turn line 516 to 525 to use:
    using (filestream…) {

    //no need to flush or close, it will be done for you.
    }

    Joe

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s