Option to ignore field/property initializers and auto-implemented properties

[rickardp]

Consider a class, e.g.

class MyClass
{
    public int MyValue { get; set; }
}

The property would be excluded because it's getter/setter has the CompilerGeneratedAttribute set. Now consider this class:

class MyClass
{
    public int MyValue { get; set; } = 42;
}

The line is included in coverage. I think this is because in the IL code, the initializers are actually part of the constructor. While this may be a sensible default even if explicitly opting out of compiler generated code, there should be an option to exclude initializers from coverage analysis.

The use case for this is when you have large model objects that contain code that you actually want coverage on, but also contains lots of pure data members.

Suggestion is to include an option, e.g. ExcludeInitializers, that ignores all initializers from coverage.

I saw e.g. issue #316, but I would argue something more specific than an arbitrary "IgnoreTrivial" is more suitable.

[rickardp]

I had a quick look at the IL code and I think it could be implemented quite easily by opting to ignore all IL code until the super constructor is called. This would work for both implicit and declared constructors.

[MarcoRossignoli]

For reference OpenCover has got -skipautoprops
/cc @tonerdo @petli

[rickardp]

@MarcoRossignoli Auto properties without initializers are already handled. Does OpenCover handle initializers?

[MarcoRossignoli]

@MarcoRossignoli Auto properties without initializers are already handled. Does OpenCover handle initializers?

Not at the moment
https://github.com/OpenCover/opencover/blob/67980c8132b1d574beb1feaa7d269c9dca47b812/main/OpenCover.Framework/Symbols/CecilSymbolManager.cs#L328
For now we'll implement same feature, ctor initialization is a bit complex to handle, we could have also other(non autogenerated) code inside ctor.

[svengeance]

Just passing by - I was able to use this today effectively, as the overall coverage % wasn't valuable to me while I was unable to skip such trivial code. I was searching for such a feature all of Friday, and just saw it in the documentation today.

So thank you, this was wonderful timing.

[ulrichb]

As of coverlet.collector 1.3.0 this still doesn't seem to work:

My config:

<?xml version="1.0" encoding="utf-8"?>

<RunSettings>
    <DataCollectionRunSettings>
        <DataCollectors>
            <DataCollector friendlyName="XPlat code coverage">
                <Configuration>
                    <Format>opencover</Format>
                    <Include>[...snip...]</Include>
                    <ExcludeByAttribute>GeneratedCodeAttribute,TestSDKAutoGeneratedCode</ExcludeByAttribute>
                    <ExcludeByFile>**/*.Designer.cs</ExcludeByFile>
                    <IncludeTestAssembly>true</IncludeTestAssembly>
                    <SkipAutoProps>true</SkipAutoProps>
                </Configuration>
            </DataCollector>
        </DataCollectors>
    </DataCollectionRunSettings>
</RunSettings>

[ulrichb]

... oh just saw that #912 has't been released yet. Right?

[MarcoRossignoli]

Right?

Yep

[wdspider]

    public sealed record RouteResponse
    {
        public string Id { get; init; } = string.Empty;
    }

I'm still experiencing that autoprops like these in records are still counting against coverage even though SkipAutoProps is set to true. Will the fix mentioned in the thread above fix this issue too? If so, when will it be released for the coverlet.collector ?

[Malivil]

This change has already been implemented and doesn't cover the case where an auto-prop has an inline assignment like that.
I would file another issue about that so it can be handled separately.

[wdspider]

This change has already been implemented and doesn't cover the case where an auto-prop has an inline assignment like that.
I would file another issue about that so it can be handled separately.

Opened #1139 as requested.

[StingyJack]

Consider a class, e.g.

class MyClass
{
    public int MyValue { get; set; }
}

The property would be excluded because it's getter/setter has the CompilerGeneratedAttribute set. Now consider this class:

@rickardp - If its reporting a class member that is unused or untouched by any of the unit tests it should be reported as not covered. Is this what you mean?