CoverageExclude

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.

13 Comments

  • 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
    www.ringrose.name
    email address on website

  • 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?

  • 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.




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

  • CoverageExclude.. He-he-he :)

  • CoverageExclude.. Awesome :)

  • CoverageExclude.. Smashing :)

  • composed by hsm 2012-06-05

  • GJTRSDGSADASDFHGAD FGBNFASDGASDDSFGHADS
    ERYERASDGASDADSFHGADFS ERYERSDGSADSDGASD
    ZVXZADFGASDGSDFH SDGSDSDGSADDSFGHADS
    ADFHGADFGASDGSDGASD ADFHGSDGSADADFHAD

  • DSGAADFGASDGASDFHGAD GJTRZSDGASDASDGHASD
    YUYSDGSADGSDGASD ASFDZSDGASDADSFHGADFS
    YUYZSDGASDADFHGAD ERYERADFGASDGASDFHGAD
    DSGAASDGASDDSFGHADS FGBNFADFGASDGASDFHGAD

  • ZVXZSDGSADXZCBZX YUKYSDGSADGADFHAD
    GJTRADFGASDGXZCBZX ASFDSDGSADADFHAD
    ZVXZADFGASDGADFHGAD YUYZSDGASDADFHAD
    SDGSDSDGSADXZCBZX FGBNFZSDGASDSDGASD

  • ERYERSDGSADSDFH FGBNFADFGASDGXZCBZX
    ASFDSDGSADASDGHASD ERYERSDGSADSDFH
    YUKYSDGSADGXZCBZX QWERADFGASDGADFHAD
    ADFHGADFHGDAFASDFHGAD DSGAADFHGDAFXZCBZX

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

Comments have been disabled for this content.