Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 4.8.6 does not produce accurate coverage reports for generic classes anymore #408

Closed
rokeller opened this issue Mar 4, 2021 · 9 comments
Labels

Comments

@rokeller
Copy link

rokeller commented Mar 4, 2021

As of the latest release of the global tool (4.8.6), reports generated for generic classes are no longer accurate.

Console output of ReportGenerator:
2021-03-04T10:59:40: Arguments
2021-03-04T10:59:40: -reports:D:\GitSrc1\common\Common.Data\Coverage\Temp*\coverage.cobertura.xml
2021-03-04T10:59:40: -reporttypes:HtmlInline_AzurePipelines_Dark
2021-03-04T10:59:40: -targetdir:D:\GitSrc1\common\Common.Data\Coverage
2021-03-04T10:59:40: -assemblyfilters:-
.Tests
2021-03-04T10:59:40: -filefilters:-*.g.cs
2021-03-04T10:59:42: Writing report file 'D:\GitSrc1\common\Common.Data\Coverage\index.html'
2021-03-04T10:59:43: Report generation took 2.9 seconds

It looks like all classes with generic type parameters are affected by this. However, the below minimal class and test easily show the problem too:

public class GenericClass<T>
{
    public string GetType()
    {
        return typeof(T).FullName;
    }
}
using Xunit;

public class GenericClassTests
{
    [Fact]
    public void ItWorks()
    {
        Assert.Equal("System.Int32", new GenericClass<int>().GetType());
    }
}

While the test does succeed and clearly covers the code, the generated report does report 0 uncovered lines, but also reports 0 covered lines which is clearly wrong.

@danielpalme
Copy link
Owner

Sorry for that.
I fixed it in release 4.8.7.

@rzikm
Copy link

rzikm commented Mar 27, 2022

It seems to me that the issue has resurfaced again (report-generator-cli 5.1.3.0), can you please look into it, @danielpalme ?

@danielpalme
Copy link
Owner

@rzikm
I did not change handling of generic classes.
Do you have a concrete example which I can use to reproduce your problem?

@rzikm
Copy link

rzikm commented Mar 27, 2022

I can reproduce this with the same code as rokeller posted above, but basically:

  • extract reportgeneratorbug.zip somewhere
  • cd into reportgeneratorbug/UnitTests
  • dotnet-coverage collect "dotnet test" -f cobertura
  • reportgenerator -reports:output.cobertura.xml -targetdir:report -reporttypes:html

Although the cobertura report contains section for GenericClass with 100% coverage, the class is missing from the report completely.

@danielpalme
Copy link
Owner

Thanks for the example. Will have a look.

@danielpalme
Copy link
Owner

danielpalme commented Mar 27, 2022

If you use dotnet-coverage collect "dotnet test" -f cobertura the coverage file contains:

<class line-rate="1" branch-rate="1" complexity="1" name="DotnetSandbox.GenericClass&lt;T&gt;" filename="Program.cs">

If you use dotnet test --collect:"XPlat Code Coverage" instead, the coverage file contains:

<class name="DotnetSandbox.GenericClass`1" filename="Program.cs" line-rate="1" branch-rate="1" complexity="1">

So with dotnet-coverage the class name contains <T> and the the class gets filtered out by

.Where(name => !name.Contains("$") && !name.Contains("<"))

This won't be easy to fix. I can't just remove && !name.Contains("<"), because this will list too many compiler generated classes:
Some examples from https://github.com/danielpalme/ReportGenerator/blob/main/src/Testprojects/CSharp/Reports/Cobertura_dotnet-coverage.xml:

  • Test.Program.<CallAsyncMethod>d__1
  • Test.AsyncClass.<SendAsync>d__0
  • Test.TestClass2.<>c
  • Test.TestClass2.<>c__DisplayClass14_0

@rzikm
Copy link

rzikm commented Mar 27, 2022

I see, thanks for the info about dotnet test --collect:"XPlat Code Coverage". It will actually work better for my use case since it lists only classes from my code.

Just an idea, maybe you might be able to differentiate between compiler-generated classes and regular classes by checking where the <> chars occur. My guess is that compiler-generated classes start with '<' (which generics don't) and never end with '>' (which generics do).

Since the issue with format differences between dotnet test and dotnet-coverage is different than the original one filed here, shall I file a separate issue?

@danielpalme danielpalme reopened this Mar 28, 2022
@danielpalme
Copy link
Owner

No need to file a separate issue. Will have a look within the next days.

@danielpalme
Copy link
Owner

@rzikm
I improved the filtering in release 5.1.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants