Geek Answers Handbook

Unit Coverage for Unit Testing

This is about .NET libraries (DLLs).

What are the options for measuring code that is covered by unit test cases? Is it really worth the effort (measuring code coverage)? Interestingly, it would be too easy to cover 70% of the code and it is almost impossible to go beyond 90%.

[EDIT] Another interesting question (suggested by Rolnitzky): What is considered a reasonable% coverage?

+4
source share
6 answers

NCover (both commercial and open source with the same name) and the code coverage tool in Visual Studio are pretty much your core tools in the MS world.

Code coverage is the inverse metric. It really does not show you which code is adequately checked. Like Nick, you can take the test, but you don't test very much. Code coverage instead tells you in which area of ​​your code there are absolutely no tests. From there, you can decide whether it makes sense to write tests for this code.

In general, I think that you should do code coverage, since it does not require much effort to configure, and at least gives you more information about your code than what you had before.

I agree that getting the last part of the code is probably the most difficult, and there may be a point where the ROI on it just doesn't make sense.

+9
source

NCover helps show you the lighting. Coverage is incredibly useful, unfortunately, you can obviously play it. If you have poor code developers to get% age, yes, it will ultimately be worthless and hide unclosed areas. Once you start these people, you can fix it and return to the helpful information. Setting coverage goals that are unattainable is a reliable way to get poor coverage.

+3
source

If you are testing, your code should be at least 70% without trying. In some areas, you simply cannot, or it’s pointless to have test coverage, that is where the NoCoverage attributes for NCover come in handy (you can mark classes that will be excluded due to code coverage).

Code coverage should not be respected religiously, it should just be a useful way to give you tips in areas you missed through testing. It should be your friend, not the Nazi!

+3
source

There are two things to consider when considering coverage code.

  • Code coverage is a battle for profit reduction: for a certain point, each additional percentage gives a lower value. Some code (e.g. core libraries) should be 100% covered, while code / user interface interactions can be very difficult to cover.
  • Code coverage is a metric that can cheat: 100% code coverage does not correspond to a fully tested application.

Take for example this snippet:

if (a == 2) { do_A_Stuff(); } if (b == 3) { do_B_Stuff(); }

Run the test where a = 2 and the second test, where b = 3. This is 100% code coverage. But what happens when with the test, where a = 2 and b = 3? These are “variable relationships” and can lead to overconfidence in coverage rates.

+3
source

I have not used it personally, but one of my colleagues swears by nCover ( http://www.ncover.com/ ).

In terms of coverage, at least in Ruby, 70% is easy, 90% is doable, and 100% is rare.

+1
source

Visual Studio Team System Developer Edition includes code coverage. This can be included when performing unit tests.

Open .testrunconfig and choose for which assemblies you need data.

+1
source

More articles:


All Articles