Code coverage and Unit tests in VS2012

This post is about a question that people often asks when writing Unit tests and What troubles a developer is:

When should I stop writing Unit tests of something(Let say a simple Function)?

Lets talk about something known as Code coverage feature in visual studio(Premium/Ultimate editions). Most of the people don’t even know how it can help identifying unused code. Code coverage actually do the instrumenting of the assembly with special symbols putting over each statement and then analyse if that is being called when the code was getting executed. In visual studio this feature is added with Test manager. So you can run your unit tests via coverage tool and analyse the report how much production code is being covered by your unit tests.

Lets see how to run tests with coverage in simple steps:

1. In visual studio 2012 (Premium/Ultimate) you’ll find the option Test –> Analyze code coverage. Now there’s an option to run a single test coverage or all tests coverage.


Note: This option will be enabled only when your solution have UnitTests available. For unit tests written with Nunit you will need an Nuget package for Nunit Test Adapter. If you want then you can also download the Nunit VS Extension by searching into the VS Extension online.

2. Now select Run All Tests option and the magic will start. The coverage tool will be automatically launched and will run all Unit tests.

3. Once all the unit tests are done with running. You’ll see a coverage report in Code coverage Results window which will give you coverage in %.


In this report you’ll see in the Covered column the percentage of every function. And if this report says 100% then

Writing Unit tests at the moment.

Though as a standard testing strategy you can stop when coverage is >95%.


  1. The problem with code coverage and Visual Studio approach to unit testing is that it gives programmers false sense of safety. Unit testing is *not* about testing every method or every line. It is *not* about generating unit tests for every *method*.
    Unit tests should test single program *functions* or *aspects*, e.g., "empty a shopping cart when there's no items in it" name your testing methods after the expected functionality, not by prepending your method name with "test" prefix...

    Grzegorz Grzybek

  2. I agree with you but it's no harm to use it wisely. Yes we don't write test to cover 100% of assembly code. But we can ensure what function/class we're testing must be 100% covered by unit testing. If it's not covering then there's something which either not covered or not required.