ryanluker
[improvement] Differentiating uncovered because not tested or filtered
Is your feature request related to a problem? Please describe. I use a filter on JaCoCo (Java) to exclude some classes from the coverage report (generated classes, POJO, Spring properties classes, Spring configuration, etc.). When I "watch" for the coverage, the filtered classes appear as "uncovered".
Describe the solution you'd like I would like my filtered classes to appear as "filtered" or "excluded" instead of "uncovered", so I can differentiate on sight what I uncovered from what I deliberately don't want to cover.
Describe alternatives you've considered When a class / file isn't in the coverage report, it should be labelled as "filtered" or "excluded" instead of "uncovered".
Additional context When searching to improve code coverage for the quality gate in Sonar, it would be nice not wasting time on filtered classes.
@Maze-fr Interesting, thanks for the ticket!
ATM we only really support 3 coverage states (full, partial, none) as that was the direction the lcov file format provided. We would have to look into jacoco's output to see if a filtered state is possible so we can filter that out in the coverage consumer. https://github.com/ryanluker/vscode-coverage-gutters/blob/b4c638feb3e05f15c405c7764020f6dd06dd7b1a/src/files/coverageparser.ts#L93-L114
At first glance, it doesn't appear like the package we use has that exposed atm. https://github.com/7sean68/jacoco-parse/blob/master/source/index.js#L74-L97
---EDIT--- Another thought came to mind, we might be able to have a filtered / ignored list in the coverage gutters settings but that sounds annoying to keep up to date with your jacoco filtering list...
I may have a different list of filtered resources in each project, because I use a property I declared in Maven, and use it in the configuration of the JaCoCo Maven plugin. So, why I thought, is that you could read the filter property from the JaCoCo Maven plugin configuration.
I may have a different list of filtered resources in each project, because I use a property I declared in Maven, and use it in the configuration of the JaCoCo Maven plugin. So, why I thought, is that you could read the filter property from the JaCoCo Maven plugin configuration.
Hmm one option could involve parsing from the coverage file via the JaCoCo javascript module we use. https://github.com/7sean68/jacoco-parse
If that provided the filtered files, we could then filter them out in the extension to avoid seeing those as "no coverage".
A second option might involve persisting the filtered files into the vscode extension via the settings.json and then the extension could also ignore coverage (or lack of coverage) if the file path matches.
Indeed, when a file is at 0%, it appears in the JaCoCo report, while a filtered files doesn't.
Indeed, when a file is at 0%, it appears in the JaCoCo report, while a filtered files doesn't.
Interesting, this is a tricky one! I added the enhancement label and added it to the next major release.