Site navigation

Social networks

Contact us

Code Coverage

Without wasting any time, let's look at the issue in hand and imagine that you've found yourself in the following situation:

  • You have a .NET project;
  • You've prepared the NUnit-tests for this project (or you have them written);
  • You were bestowed Visual Studio 2008 Team System (or higher) or Visual Studio 2010 Premium (or higher) and charged with executing a code coverage analysis.
You could start right away, except for one little obstacle: Test Runner, integrated into Visual Studio, can browse only its own MSTests, and your NUnit is ignored as if it didn't exist. So what can you do? 

Let's scrutinize thoroughly the above-mentioned issue using a simple example. In Visual Studio (in our example it is Visual Studio 2010 Ultimate), create a new project of type Class Library and name it 'TestedAssembly.' Add only a single class 'TestedClass' to the above mentioned project; this class will include a single simple method 'GetSomeString'.

tested class

Switch to the project with tests and then add one more Class Library to 'Solution' and name it 'TestAssembly'. This build will also have the only class 'TestedClassTest' with a single method 'GetSomeStringTest'.

tested class test

Now it's high time to answer the most complicated question: How can you make Visual Studio collect code coverage data in terms of the test runs that the Studio rejects. We are actually not going to make it run those tests; this task can be achieved perfectly by NUnit instead. 

Let's add one more project to our solution; this time it'll be a project of type Test Project. We'll name it 'NUnitProxy'. The Studio will automatically add UnitTest1.cs file into it. Now we can easily delete this file and add a Generic Test. It is necessary to show the complete path to nunit-console-x86.exe in the first field of text settings (note: make sure you use x86 - it's of great importance). A complete path to the assembly of the tests should be shown in the second field (see the TestAssembly project as per our example). 

Make sure you use the quotation marks in the Command Line - they are obligatory!

proxy generic test

Now go to the /Solution Items folder which appeared in the Solution as if by magic as soon as NUnitProxy project was added. Double-click on Local.testsettings file. (see diagram below)

solution explorer

You can now see the 'Test Settings' dialogue. 

Go to the Data & Diagnostics inlay, tick the Code Coverage option and click on the [Configure] button :and you are done - its as simple as that! 

The Code Coverage Detail window gives you the opportunity to select assemblies and then Visual Studio will collect Code Coverage data for those particular assemblies. 

Here you should take into account one minor issue: if you select an assembly from \bin\Debug\ directory of the project being tested, you will be surprised with the analysis results. The results will show nothing, but a less-than-fascinating empty space. Now click on Add Assembly: and indicate the path to the assembly that is stored in \bin\Debug\ directory of the project with tests (see TestAssembly as per our example). Make sure that the 'Instrument assemblies in place' option is checked and then feel free to press the [OK] and [Apply] buttons or close the window [X]

code coverage detail

And that's all there is to it! Visual Studio can now see our proxy-test. You can run it and see NUnit console open. When the tests are performed, go to the Code Coverage inlay and be pleased with more fascinating and definitely more meaningful results.

code coverage results

I can't help but add two little flies into the ointment. First of all, Visual Studio cannot work with x64 assemblies and it brings undesirable consequences: if you want Code Coverage, you have to recompile for x86 (any CPU works just as well). Secondly, if the code in assembly is not covered at all, then this assembly will not be included into the final report (you can check it through commenting 'GetSomeStringTest' methods). The latter can lead to incorrect value of the final coverage in some cases (for instance, when the data are collected for different assemblies). 

I hope this little tutorial has been useful and helped you with your coding skills. I will be back again with some more useful and in-depth programming tips again soon - bookmark this page!
Andrey Kudievskiy



Not just another web and mobile apps development company!

WeezLabs is about dreaming big and helping our clients reach their full potential.



1848 Lincoln Blvd, Suite #100,
Santa Monica, CA 90404



Call us 310.776.6234 or complete the form below.