Mismatch between Branch Coverage in Cobertura and HTML reports
See original GitHub issueWe are generating code coverage using dotnet test, coverlet, and cobertura. We are using ReportGenerator to combine the coverage results and generate both Cobertura and HTML reports. We are also integrating with Build Quality Checks to gate the builds if line or branch coverage dips below a certain threshold.
We would very much like for the HTML reports to show the same numbers that the build gates will trigger off of. It’s obviously very confusing to see a build fail because branch coverage is too low, but look at the Code Coverage tab and see that it’s clearly above the require threshold.
I know this is related to other issues that have been closed related to how RG counts branches vs. how cobertura does. However, since RG is responsible for generating the combined cobertura.xml file, couldn’t it use its own count when generating the coverage element in that file so that it matches the HTML output?
See related issue here with screenshots and more details: https://github.com/MicrosoftPremier/VstsExtensions/issues/120
Thanks!
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (3 by maintainers)

Top Related StackOverflow Question
Problems solved!
In working with the team that had this problem I discovered that while they were combining 3 cobertura files, they were only running 2 tests (the 3rd was commented out). However, the 3rd had its cobertura.xml file checked into source control (some time ago) so it was being combined via RG with the other 2.
The lack of the
disable.coverage.autogenerate: 'true'hid this problem since the HTML seemed to show the right result. Adding that in got the HTML report to match the RG-generated cobertura.xml file. Removing the old cobertura coverage file from source eliminated the problem entirely.Yes, I’ll email them today from my client computer. We did manage to get consistent results between HTML and cobertura.xml files by setting the disable.autogenerate to true. Unfortunately, it’s now reflecting the low coverage numbers in both places, because it’s not taking into account our exclusions.