Questions about multi-targeting and overall coverage report.

[chtoucas]

Hello, let's say that I have a project with more than one target. It appears that MultiReportParser indicates 100% CC even if it's not the case for one of them. In other words it seems to take the best result when merging the reports.

Is it intended? Is there an option to change this behaviour?

[danielpalme]

No that's neither intended nor should it be the case.

If you pass several coverage files to ReportGenerator it does the following:

• Get all assemblies and all classes from all files
• Merge assemblies and classes if name(s) are the same
• Determine coverage for every class in every assembly. If a line is executed/visited in at least one of the coverage files it is treated as covered
• Total line coverage is calculated by number of covered lines divided by number of cover able lines

Do you have a concrete example where this is not working? If your like, you can send your coverage files by email, then I can have a look.

[chtoucas]

Thanks, I just sent you the coverage files to your email.

[danielpalme]

If you look at the relevant line 34, you get the following result for:

• coverlet.net452.xml
• coverlet.net461.xml
• coverlet.netcoreapp2.1.xml

For coverlet.netcoreapp3.1.xml you get:

If you combine the all coverage files, you also will get this result:

Reason can be found in coverlet.netcoreapp3.1.xml in line 3178

<SequencePoint vc="18" uspid="34" ordinal="6" sl="34" sc="1" el="34" ec="2" bec="2" bev="2" fileid="16" />

This indicates that line 34 of your class was executed 18 times (see vc-attribute). When files are merged, the visit count of all files gets summed up and you'll get 100% coverage. That behavior is intended, since all lines are covered in at least one of the coverage files.

By the way: The uncovered line is marked red and not green as you stated in your email.

[chtoucas]

Sorry, I think I didn't explain myself very well. I totally agree with your analysis, I saw the same thing and it surprised me. I expected the tool to pick up the worse result not the best one. If the line 34 is indeed covered for netcoreapp3.1, it is still not the case for the three other targets. If I had just looked at the merged report, I wouldn't have realized that. In the end, I did have to add a test to achieve 100% code coverage.

I understand now that it is the intended behaviour, and I am fine with that, I just wanted to be sure. By the way, thanks a lot for RG, it's an extremely useful tool.

(My remark on the color was for the merged report, which is green indeed, normal considering what you wrote)