Visual Studio .coveragexml: ReportGenerator ignores compiler-generated classes about reportgenerator

[danielpalme]

Thanks for the detailed description and the sample.
I will have a look as soon as possible.

[RoadTrain]

We have been digging further, and now I'm not sure there's a problem with the library. Please put this on hold, I'll be back with a verdict shortly.

[danielpalme]

They only thing that we would like to have is the ability to "see" these functions, i.e. be able to extract their metadata with ReportGenerator.Core library to show them on our dashboard, without affecting metrics.

I will see what I can do. Will come back to you as soon as possible.

[RoadTrain]

Thanks! I will test it in the following days and come back.

[RoadTrain]

After taking a quick glance at the code, I can see two things:

1. Currently there's a special case for compiler-generated iterator methods:

   ReportGenerator/src/ReportGenerator.Core/Parser/VisualStudioParser.cs

   Line 333 in 282bdbe

   if (methodKeyName.Contains("MoveNext()"))

2. Lambdas (and consequently local functions) are excluded (which dates back to the initial import in 2015):

   ReportGenerator/src/ReportGenerator.Core/Parser/VisualStudioParser.cs

   Line 245 in 282bdbe

   || LambdaMethodNameRegex.IsMatch(fullName))

[danielpalme]

I just found time to have a closer look. Sorry for the delay.

The main problem is that line and block coverages of these local functions is lost in the generated report. We have classes which mainly consist of local functions, and the coverage metrics are very off for them, compared to what Visual Studio shows.

Compiler generated classes are not listed on the summary page, that's correct. But the relevant lines are processed within the corresponding parent class.
In your example the summary report only shows the classes MyLogic and MyScenario.
But if you look into the MyScenario report, you will see that all coverable lines are considered. Even the block with line 729-738, which belongs to a compiler generated class.

1. Currently there's a special case for compiler-generated iterator methods:

Yes, but that's just a naming thing. The name MoveNext is not very helpful, instead the "correct" method name is retrieved.

2. Lambdas (and consequently local functions) are excluded

Yes, but only in the list of methods and their metrics. This does not affect the overall code coverage.

Does this help? I'm I missing something?

[RoadTrain]

The main issue we had is the 'Blocks covered' method metric which was incorrect (i.e. apparently not including compiler-generated local functions). It seems to me that the Lines metric is calculated correctly indeed.

Can you take a look at how it's calculated? Maybe the same 'aggregation' logic is missing for block coverage?

[RoadTrain]

And what about properties? They are excluded from the report too, do they count towards line metrics like compiler-generated methods do? In theory, property getters/setters can (and often do) have some logic in them, so they should count towards line/block coverage metrics.

[RoadTrain]

So our current understanding is that including lambda/local functions in total metrics (as suggested by me) is incorrect because they are already included by Visual Studio coverage. So the premise of this bug report is false, sorry for that.

They only thing that we would like to have is the ability to "see" these functions, i.e. be able to extract their metadata with ReportGenerator.Core library to show them on our dashboard, without affecting metrics.

[danielpalme]

I think I have found a solution. Will publish a new release in the next days.

[danielpalme]

Release 5.1.26 is now available. Could you please test if this works for you?