Coverage does not distinguish between property getters and setters

Coverlet doesn’t appear to differentiate between property getter and setters when calculating coverage.

For example, given a project with only this simple class:

class MyClass
{
    private bool mandatory;
    public bool Mandatory { get => mandatory; set => throw new NotImplementedException(); }
}

And the test project only has the following test:

[Fact]
public void CheckMandatoryDefault()
{
    var sut = new MyClass();

    Assert.False(sut.Mandatory);
}

The test passes, the property is read via it’s getter, the setter is not called (i.e. the exception is not thrown) yet the coverage report says 100% coverage. I expected that the coverage report to show 50% coverage.

For completeness I tried changing the Mandatory property to use the following rather than expression bodies for the getter/setters in case the compiler was emitting some compiler generated attribute for expression bodies but it made no difference:

public bool Mandatory { get { return mandatory; } set { throw new NotImplementedException(); } }

[SteveGilham]

@MarcoRossignoli The original NCover 1.x recorded start/end line/colum in its XML report, and for viewing classic NCover reports, the NCoverExplorer tool would show this level of detail and its coverage percentages are of the sequence points rather than lines (as is the summary emitted by OpenCover – which followed NCover in emitting sequence point start/end line/column information in the XML – at the end of its run).

[jeffanders]

@MarcoRossignoli There definitely seems to be some overlap (no pun intended) with this issue and #369 and your work on it. It looks like your work already improves the situation for lambdas at the very least (and presumably anonymous delegates). I have subscribed to that other issue and once it is complete/merged I will see if I have time/inclination at that point to circle back to this issue, see how it is affected by your changes and what remains outstanding and whether considering each of the aforementioned items as new branches under a separate command line switch is justified.

Thanks for the discussion thus far, it has been very interesting.