Hi, thanks for posting! I'm happy to seeing you taking NCrunch for a spin and I hope it lives up to your expectations.

Both of these points above are by design, though I accept that the underlying behaviour is not exactly clear.

In the first case, NCrunch only obtains code coverage information using line-by-line resolution. This means that if you have two statements of code written on one line of code, NCrunch will process code coverage on both statements together and treat them as a single line. In your example above, because the condition itself is executed (even though the return is not), NCrunch will still consider the line of code covered. Broadly, the reasoning behind this is implementation-specific:
- Because the line markers are only shown on a line-by-line basis (as opposed to other code coverage tools, where coverage is highlighted), it is difficult to show coverage for both statements using the same marker. Suggestions have been raised such as splitting the marker in half, although the markers themselves can be customised, which makes this complicated.
- NCrunch is required to merge and process massive amounts of coverage data in real-time, making any activity around the coverage information performance critical. Moving from line-by-line resolution to statement-by-statement resolution would add a whole new dimension of complexity making it even more challenging for the engine to perform adequately (in other words, it's really really hard to do).

In the second case, NCrunch won't show the last line of code as being covered, because it actually isn't covered. If you set a breakpoint on this line and debug the test, you'll notice that the line is never hit. By throwing an exception from the test, you are exiting the method part-way through its execution. For NCrunch to simply show the last line as covered for the sake of completeness would basically be lying :) If you're concerned about your coverage statistics, try placing the comment '//ncrunch: no coverage' at the end of the line of code to instruct NCrunch not to instrument it.

I hope this helps!


Cheers,

Remco

Hi Søren,

As a general practice, I would recommend placing your IF statements and actions on different lines. This can make the code easier to debug (using breakpoints), and with NCrunch it will give you more details visibility on your code coverage.

Ternary operators are an interesting case. As the expressions inside ternary operators are generally best left to simple and concise logic, it could be argued that if you were interested in seeing code coverage between the different branches of the condition, then you might be better off not using a ternary operator and instead creating an IF statement that spans multiple lines.

One way you could look at this is that if you were interested enough in the separate branches of a conditional statement that you want to see code coverage in NCrunch, then having the branches on separate lines would be an advantage for you anyway as it would give you the capability to place breakpoints in more granular places.

Anyway, I am a believer in the idea that a toolset should support the way you WANT to develop the code rather how the developer of the toolset THINKS you should develop the code. Which does more or less make the above comments more of a 'Remco recommends' rather than 'thou shalt'. The reason for the current implementation is basically the difficulty in producing anything better, rather than what I think people should or shouldn't do. I've definitely taken your comments on board and if I can find a future opportunity to make this work then I will be looking into it in more detail :)


Cheers,

Remco