-
-
Notifications
You must be signed in to change notification settings - Fork 272
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
Visual Studio .coveragexml: ReportGenerator ignores compiler-generated classes #625
Comments
Thanks for the detailed description and the sample. |
After taking a quick glance at the code, I can see two things:
|
I just found time to have a closer look. Sorry for the delay.
Compiler generated classes are not listed on the summary page, that's correct. But the relevant lines are processed within the corresponding parent class.
Yes, but that's just a naming thing. The name
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? |
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? |
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. |
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. |
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 |
I will see what I can do. Will come back to you as soon as possible. |
I think I have found a solution. Will publish a new release in the next days. |
Release 5.1.26 is now available. Could you please test if this works for you? |
Thanks! I will test it in the following days and come back. |
Describe the bug
Hi!
When class methods contain local functions, the .net compiler (roslyn-era) generates separate classes for them. These classes (and their methods) are ignored by ReportGenerator, while there can be a lot of logic in them. 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.
I have found a very similar issue which was closed without resolution #120.
To Reproduce
I have attached a sample hand-crafted coveragexml where class
MyScenario
contains both a class method and two local functions and a resulting report. Line numbers are off but it doesn't matter because you can still see the main problem -- compiler-generated classes are ignored.vs_issue_sample.zip
The text was updated successfully, but these errors were encountered: