Hi and happy NY,
Re.
[img=http://i.imgur.com/SLp1i.png]NCrunch color problem[/img]
Shouldn't all the lines for this statement be colored as green?
Regards,
Lars Wilhelmsen
General Feedback
NCrunch not showing correct color "balls" in the gutter
Started by larsw on 12,413 views
Remco NCrunch Developer
#3480
03 Jan 2013 09:55 UTC
Hi Lars,
Thanks for posting and happy new year!
It is difficult to tell whether the lines should be green or not, as this would depend upon the execution manner of this expressions in this statement.
With the exception of the first line of the statement, the code shown above will not execute until it is hit by an enumerator of some kind. The lambda expressions form an enumerable for which the execution is deferred until later in the program.
You'll probably find that if you put a .ToList() at the end of the statement, all the lines shown above will turn green. I hope this makes sense.
Cheers,
Remco
Thanks for posting and happy new year!
It is difficult to tell whether the lines should be green or not, as this would depend upon the execution manner of this expressions in this statement.
With the exception of the first line of the statement, the code shown above will not execute until it is hit by an enumerator of some kind. The lambda expressions form an enumerable for which the execution is deferred until later in the program.
You'll probably find that if you put a .ToList() at the end of the statement, all the lines shown above will turn green. I hope this makes sense.
Cheers,
Remco
Edited 03 Jan 2013 09:55 UTC
Hi again Remco,
I'm fully aware of the deferred nature of executing chained LINQ expressions on enumerables - but what my screenshot does not show (sorry for that), is that the enumerable is in fact
iterated over further down in the code file, so the code is in fact run (I've also verified it in the debugger).
I will try to isolate a test case.
--larsw
I'm fully aware of the deferred nature of executing chained LINQ expressions on enumerables - but what my screenshot does not show (sorry for that), is that the enumerable is in fact
iterated over further down in the code file, so the code is in fact run (I've also verified it in the debugger).
I will try to isolate a test case.
--larsw
Remco NCrunch Developer
#3487
03 Jan 2013 22:31 UTC
Sorry. It may be that this is a mapping problem then. If you're able to put together a complete sample, I'd really like to take a look!
Cheers,
Remco
Cheers,
Remco
Hi again,
After a deeper investigation, it seems that it is my test rig that left out enumerating an input in a mock (e.g. I forgot to do something about the input, I only returned a mocked return value).
Fixing that and the balls turned green :)
--larsw
After a deeper investigation, it seems that it is my test rig that left out enumerating an input in a mock (e.g. I forgot to do something about the input, I only returned a mocked return value).
Fixing that and the balls turned green :)
--larsw
Remco NCrunch Developer
#3492
04 Jan 2013 22:24 UTC
Great to hear! Thanks for letting me know :)
Hi again Remco,
Had a discussion with a colleague where he points out an interesting thing; in the example code above,
if I had not split the chained statement over multiple lines (e.g. I had inlined it all on one line) the ball would go green,
even though not all of the code had been exercised.
May it be the same case with conditional expressions?
if (foo() || bar() || baz()) <-- if foo() returns true, then bar() and baz() would not be called at all.
{
// ...
}
?
I know that the built-in Code Coverage functionality in Visual Studio can color lines as partially covered - might this be something
to look into for the next release?
--larsw
Had a discussion with a colleague where he points out an interesting thing; in the example code above,
if I had not split the chained statement over multiple lines (e.g. I had inlined it all on one line) the ball would go green,
even though not all of the code had been exercised.
May it be the same case with conditional expressions?
if (foo() || bar() || baz()) <-- if foo() returns true, then bar() and baz() would not be called at all.
{
// ...
}
?
I know that the built-in Code Coverage functionality in Visual Studio can color lines as partially covered - might this be something
to look into for the next release?
--larsw
Remco NCrunch Developer
#3506
11 Jan 2013 08:53 UTC
Hi Larsw,
You are absolutely correct. This is caused by the limited resolution in which NCrunch captures the code coverage data during execution - it basically handles it on a line-by-line basis rather than statement-by-statement basis.
There have been a few suggestions on this forum around how to visualise lines as partially covered, for example, by making the coverage markers appear half full.
I'd like to address this issue, although at this stage I'm not yet sure as to the feasibility. The NCrunch mapping algorithm is a fairly extreme piece of code and it may be difficult to keep it performing adequately with a new dimension added to it. The solution to this may live on the NCrunch backlog to be looked at as part of a long term plan.
Cheers,
Remco
You are absolutely correct. This is caused by the limited resolution in which NCrunch captures the code coverage data during execution - it basically handles it on a line-by-line basis rather than statement-by-statement basis.
There have been a few suggestions on this forum around how to visualise lines as partially covered, for example, by making the coverage markers appear half full.
I'd like to address this issue, although at this stage I'm not yet sure as to the feasibility. The NCrunch mapping algorithm is a fairly extreme piece of code and it may be difficult to keep it performing adequately with a new dimension added to it. The solution to this may live on the NCrunch backlog to be looked at as part of a long term plan.
Cheers,
Remco
Post a reply
Log in to reply.