2

I am trying to achieve 100% code coverage. However, somehow code coverage is complaining about some MoveNext() method that is not covered, however, there is no code path that's iterating an IEnumerable...

Code coverage result

Code snippet

Any ideas how to cover the MoveNext method? Where is the MoveNext() located?

Identity
  • 1,553
  • 1
  • 22
  • 44
  • 5
    It's related to the async/await code - `MoveNext` is part of the autogenerated logic. Out of interest, what code coverage tool are you using, perhaps it doesn't understand async/await? – James Thorpe Mar 29 '17 at 11:57
  • 3
    Note the class name. It's clearly a compiler-generated IEnumerable. I guess your code coverage tool doesn't bother to check whether it's actually code you wrote that should be covered. However, I found trying to strive to 100 % code coverage fairly useless except for tiny toy projects. In any larger project there's always some statement or expression you're not going to be able to cover. Oftentimes those are just safeguard `throw`s for things that should never ever happen and the like. – Joey Mar 29 '17 at 12:00
  • @Joey class name indicates that this is async state machine, not IEnumerable. Well maybe it might indicate both, but in this case we see from code that it's not an IEnumerable. – Evk Mar 29 '17 at 12:01
  • Look at this answer: http://stackoverflow.com/a/4047607/2420998. It shows the generated code of an async method. What is called `Step` in that answer is also called MoveNext(). – vyrp Mar 29 '17 at 12:02
  • I think he's using Visual Studio builtin code coverage tool. It's under the Test menu. I don't know if Community has it though. https://msdn.microsoft.com/en-us/library/dd537628.aspx – vyrp Mar 29 '17 at 12:09
  • @Joey out of interest I verified and indeed both async state machines and IEnumerable iterators use the same compiler-generated names (Type..d__X). – Evk Mar 29 '17 at 12:12
  • 100% code coverage will make you do stupid things to achieve it. Just don't do it – Keith Nicholas Mar 31 '17 at 01:43
  • @JamesThorpe but there are multiple paths. If you await and the task is already in the `Completed` state vs a not completed state the state machine takes two very different paths. A code coverage tool needs to show both paths. – Scott Chamberlain Mar 31 '17 at 02:12

2 Answers2

5

Honestly, and I'm speaking from experience of trying to attain and maintain 100% code coverage for a medium sized project with an average sized team where the code followed SOLID principles reasonably well, you should forget trying to achieve 100% code coverage.

Best practices suggest that, for good reason, a system with 70% coverage is pretty good, 80% very good, 90% exceptional. It sounds like you're in the high nineties, so you be proud, and not overly worry about that final piece which, by the sounds of it, isn't even testing your code base per se. Or to put it another way, would you rather hit that 100% holy grail or spend the time refactoring code to make future maintenance easier ?

When I tried maintaining 100% coverage I was new to C# and ended up writing unit tests to test the .Net framework's getters and setters - I thought I was really clever hitting 100% (for all of one week until someone in the team added a few lines of ultra-somple code) and then someone politely pointed out the stupidity of some of my tests - what a fool I felt.

I realise that my "answer" does not actually answer your question, and I started off this response as a comment, not an answer, but as I was writing I realised that my comments were so relevant that even without directly answering the question a mere comment was an insufficient explanation. I truly admire any attempt at 100% coverage, but don't get hung up on achieving it - "done is better than perfect".

Good luck nevertheless !

Greg Trevellick
  • 1,361
  • 1
  • 16
  • 26
1

What worked for me was to exclude the MoveNext() method in the .runsettings file for my solution:

        <Functions>
          <Exclude>
            <Function>.*MoveNext.*</Function>
          </Exclude>
        </Functions>

See this related Stack Overflow post.

Tony S.
  • 21
  • 3