Eric Sink recently wrote an article, advocating the use of code coverage. In the article Eric writes about a hobby project of his where he has managed to achieve 100% code coverage. The following may be of interest to anyone who finds themselves driven towards such ridiculous levels of coverage. ;)

When using NCover, particular methods and classes can be marked with an attribute so they are excluded from the coverage report. TestDriven.NET tell NCover to use an attribute called 'CoverageExcludeAttribute' as this special attribute. When using the NCover console application, this option is:

//ea CoverageExcludeAttribute

The 'CoverageExclude' attribute isn't defined in an external assembly. This is because 'CoverageExclude' is most likely to be used in non-test code. We don't want to create a dependency on another assembly (just as you wouldn't want to reference 'nunit.framework' from non-test code). Instead the 'ExcludeAttribute' can be defined in the empty namespace as follows:

class CoverageExcludeAttribute : System.Attribute { }

Once defined this attribute can be used to exclude specific methods and classes from the NCoverExplorer coverage report.

Published Wednesday, October 4, 2006 2:47 PM by Jamie Cansdale


# re: CoverageExclude

I wish to be able to exclude some error checking code from coverage, e.g. if (arg == null) { Throw new … } Would it be possible to write something like? if (arg == null) { CoverageExcludeBasicBlock(); Throw new … } Ian Ringrose email address on website

Wednesday, October 4, 2006 11:11 AM by Ian Ringrose

# re: CoverageExclude

sounds like a neat trick, though I have been giving CodeCoverage some though within the context of the team I work... conclusion was that it might be desirable not to measure test coverage agains code-statements, but to measure test coverage agains complexity. Since there are ways to determine the complexity of code (such as "Cyclomatic Code Complexity") it might be well possible to measure test-coverage in a way that makes more sense... Do you know about innitiatives in this direction? Does my conclusion hold?

Wednesday, October 4, 2006 11:40 AM by Olaf Conijn

# re: CoverageExclude

Jamie, the easiest (and most straightforward) way in which this could be implemented is automatically excluding stuff with a complexy of 0 (simple setter, getter, empty custructor) or another configurable complexity level. Taking it further, could mean defining a success ratio, which could be expressed as: my code coverage is acceptable if 95% of my branches are covered. This again shows success when not covering a method without branches (or complexity). This could be visualized the same way unittest success is (red=bad/green=good). Eventually you might be able te not show percentages over LOCs/ covered LOCs, but Branches/ covered branches.

Thursday, October 5, 2006 6:30 AM by Olaf

# re: CoverageExclude

Variety is the spice of life.


Tuesday, December 21, 2010 10:45 PM by penultimate ipad app

# re: CoverageExclude


I desire finding over a broken coronary heart can be so easy as following a couple of steps.! but its not…

Sunday, January 9, 2011 6:17 AM by best ipad stand

# re: CoverageExclude

CoverageExclude.. He-he-he :)

Saturday, March 26, 2011 4:40 AM by

# re: CoverageExclude

CoverageExclude.. Awesome :)

Sunday, April 24, 2011 7:56 AM by

# re: CoverageExclude

CoverageExclude.. Smashing :)

Tuesday, June 7, 2011 7:42 AM by

# re: CoverageExclude

composed by hsm 2012-06-05

Tuesday, June 5, 2012 2:44 PM by Beetafriele

# re: CoverageExclude





Wednesday, September 5, 2012 10:47 AM by GafeWrofe

# re: CoverageExclude





Wednesday, September 5, 2012 8:54 PM by Zesemensush

# re: CoverageExclude





Wednesday, September 5, 2012 9:39 PM by Absordreibe

# re: CoverageExclude





Wednesday, September 19, 2012 1:42 AM by myncWrismic

# re: CoverageExclude

Good to see some detailed information on this topic. Thanks for the share. I really appreciate it.

Friday, January 11, 2013 2:53 PM by dissertation for master's degree