Open atehrani opened 6 years ago
My thought is that we can pass an extra query parameter to indicate that we want line coverage
Here we would check to see if that query parameter is passed and then use line coverage. Otherwise use instruction coverage (as would be default and current behavior).
@atehrani - so you'd still only want one coverage badge, but be able to toggle what coverage number it uses? We could probably provide the prebaked options in the groovy file.
After discussion with @atehrani, I propose we move to a more universal coverage reporting across languages, we use LINE coverage which is supported by cobertura and jacoco, and then statement coverage for clover which is more akin to line coverage than element coverage.
Sounds good to me. Feel free to add a PR. @chetanddesai - we should really get this published on jenkins, so people can pull this from the registry...
FWIW: The goal of "coverage" is to indicate if people have written tests that cover good unit/integration use cases. Although line coverage is the most robust, it can be pretty misleading at times. Specifically around "If" statements and switches. 1 missed line coverage in those cases could seem like a small number but could have a huge negative effect. It may be controversial, but I like to lean towards branch coverage over line coverage.
The clover get method needs to change from element to statement coverage here: https://github.com/SxMShaDoW/embeddable-badges-plugin/blob/master/src/main/java/org/jenkinsci/plugins/badge/PublicBadgeAction.java#L158
This is an enhancement request to also include Jacoco: Line coverage percentage