4

Given that there appears to be no hard and fast rule as to what a good level of code coverage for unit tests is, what then are the benefits of using a code coverage tool such as NCover?

Community
  • 1
  • 1
Simon
  • 1,499
  • 3
  • 17
  • 23

4 Answers4

5

It is fallacious to measure software quality solely according to a code coverage percentage, as you've pointed out. But NCover allows you to examine exactly which parts of your codebase have been neglected by unit-testing. Since you should know which parts of the code are executed most frequently and which parts are most error-prone, NCover is useful for ensuring they're at least being tested.

asdfjklqwer
  • 3,536
  • 21
  • 19
  • I agree. Covered code doesn't say anything about the quality of the tests that cover that code. However, code coverage tools can help you spot parts of your software that isn't tested at all. – Steven Nov 15 '10 at 07:50
2

Code Coverage, as a metric gives you two important pieces of intel: First, it tells you what is covered by a unit test and what isn't. If you use this along with static analysis of the code, you can easily find complex code that is used often and isn't tested. Complex, frequently used code that isn't currently tested is code that you will want to add tests for.

Second, if you follow the trend of the code coverage, you can detect whether you are getting "better" at testing your code, or are introducing legacy code (i.e. untested code); You may wish to have your automated build run code analysis to let you know if the coverage percentage is decreasing (indicating that someone is checking in untested code).

Assaf Stone
  • 6,309
  • 1
  • 34
  • 43
2

Even if you have an agreed level of coverage, code coverage would only tell you if you meet that level, not if the tests are any good. But even with its limitations coverage (and the stats you can derive from it, such as CRAP (coverage over complexity, Clover can display the same data as tag cloud, tis very neat) is still useful for getting a rough idea how how well the code is tested and if where potential bugs will be hiding.

No silver bullets exists, but that does not mean you should not use of every regular bullet you can find. Bind them together (Code coverage with CI, trends and coverage over complexity and maybe some code mutation) and you end up with a powerful method to quickly informing you of potential issues.

Michael Lloyd Lee mlk
  • 14,561
  • 3
  • 44
  • 81
1

The main advantage of running a coverage tool on your test suite is to find areas of your code that are poorly tested. I often look at my coverage numbers by assembly, namespace, and class to find code that hasn't been tested, but really should be.

James Kovacs
  • 11,549
  • 40
  • 44
  • True... just don't trust the tool too much. They're prone to false positives, especially if they check statement coverage rather than branch coverage. – ssokolow Nov 15 '10 at 04:33
  • You have to understand the tools that you use. Coverage tools have a fair number of knobs to twist. With NCover, you can select coverage reporting based on method (was the method executed), branch, or sequence point. Other coverage tools offer the same or similar options. (No, I don't work for NCover. I just use their tools from time to time.) – James Kovacs Nov 15 '10 at 04:45