Can I exclude part of a method from code coverage?

Question

I suspect the answer is no, but I'll ask anyway...

TL;DR

I know I can exclude a class or method from coverage analysis with the [ExcludeFromCodeCoverage] attribute, but is there a way to exclude only part of a method?

Concrete example

I have a method that lazily generates a sequence of int.MaxValue elements:

private static IEnumerable<TElement> GenerateIterator<TElement>(Func<int, TElement> generator)
{
    for (int i = 0; i < int.MaxValue; i++)
    {
        yield return generator(i);
    }
}

In practice, it's never fully enumerated, so the end of the method is never reached. Because of that, DotCover considers that 20% of the method is not covered, and it highlights the closing brace as uncovered (which corresponds to return false in the generated MoveNext method).

I could write a test that consumes the whole sequence, but it takes a very long time to run, especially with coverage enabled.

So I'd like to find a way to tell DotCover that the very last instruction doesn't need to be covered.

Note: I know I don't really need to have all the code covered by unit tests; some pieces of code can't or don't need to be tested, and I usually exclude those with the [ExcludeFromCodeCoverage] attribute. But I like to have 100% reported coverage for the code that I do test, because it makes it easier to spot untested parts of the code. Having a method with 80% coverage when you know there is nothing more to test in it is quite annoying...

Answer 1

No, there is no way to exclude "part of a method" from coverage analysis with dotCover.

In the general sense you got a couple of options:

1. Extract the uncovered part into its own method, so you can properly ignore that method from analsysis
2. Ignore the problem

In this case there may be a third options. Since your test code exercises the majority of your method, perhaps you should just write a test method that makes sure the code runs to completion?

Answer 2

First and foremost, while "code coverage" can be an important metric, one must realize that it just might not be possible to have 100% "code coverage". 100% Code coverage is one of those metrics that you should aspire to attain, but which you never will; i.e. get as close as you possibly can.

OTOH, don't go crazy trying to get 100% code coverage. More importantly, is your code readable? Is it testable (I presume so since you're looking at code coverage)? Is it maintainable? Is it SOLID? Do you have passing unit, integration, and end-to-end tests? These things are more important than achieving 100% code coverage. What code coverage will tell you is how extensive your testing is (I'm not sure if the built-in code coverage analysis engine includes only unit tests, or includes all types of tests when calculating its statistics), which gives you an indication of whether or not you have enough tests. Also, while it will tell you how extensive your tests are (i.e. how many lines of code are executed by your tests), it won't tell you if your tests are any good (i.e. are your tests really testing what needs to be tested to ensure your application is working correctly).

Anyway, this may be not an answer, but food for thought.