Properties and false code coverage

I have a assembly with load of not testes classes with auto properties. In NCrunch metrics they all get 100% coverage which is totally untrue. When i convert them to properties with backing field it all works all right.

Such props should be marked black/green/ and half green when only getter is tested but not setter (and vice versa).

The same mechanizm goes for one line ifs, they should get half green dot when not all branches are coverted.

Regars,
4rchie

Hi Archie -

As the compiler doesn't emit debugging information for auto properties, they are essentially invisible to tools such as NCrunch. The metrics view will report 100% code coverage on a source file that contains no code (I'm willing to discuss the correctness of this as I understand that it may be misleading).

However, I agree with your analysis. If a technical approach can be found to solve this problem and introduce coverage markers to auto properties, this would make sense.


Cheers,

Remco

You can look for it on an IL level. Tools like NCover finds this kinds of stuff and I strongly believe that you can do it as well.

The same goes to ? and ?? operators

Consider folowing:

[Test]
public void SomeTest()
{
var result = GetResult(true);
Assert.AreEqual("Covered branch",result);
}

private string GetResult(bool condition)
{
return condition ? "Covered branch" : "uncovered branch";
}

you will get all green dots even though that the half of the GetResult is actually not covered.

Sorry - I meant that the debugging information constraints were around auto-properties. You are absolutely right about the different branches being fully detectable using more granular instrumentation at IL level - this is certainly possible.

So will NCrunch support half green indicator when using ?? operator?
In my application I use "??" operator sometimes, and I would like to be warned when still need to cover.
I am using version 1.46.0.20.

Hi -

I'm afraid that there are no firm plans yet on when this will happen, if it actually ever will happen.

This is because the complexity involved in adding an extra dimension to the code coverage tracking is too high for this feature to be feasible. Currently no planned solution exists that will allow the engine to meet an acceptable standard of performance.


Sorry.


Cheers,

Remco