Confusing coverage highlighting for python from coverage.xml

[merc1031]

Describe the bug Confusing coverage highlighting for python from coverage.xml

coverage.xml snippet

                        <line hits="1" number="697"/>
                        <line branch="true" condition-coverage="100% (2/2)" hits="1" number="699"/
                        <line hits="1" number="697"/>
                        <line branch="true" condition-coverage="100% (2/2)" hits="1" number="699"/>
                        <line hits="1" number="700"/>
                        <line hits="1" number="702"/>
                        <line hits="1" number="703"/>
                        <line branch="true" condition-coverage="100% (2/2)" hits="1" number="704"/>
                        <line hits="1" number="709"/>
                        <line hits="1" number="711"/>

highlight

It looks like lines 697, 700, 702, 703, 709 and 711 all have the same coverage, however 697 and 700 are drawn green (full coverage), and 702, 703, 704, 709 and 711 are all drawn red (missing coverage).

Am I just misreading this?

Desktop (please complete the following information):

• OS: windows (but extension enabled on ssh linux machine)
• Extension Version v2.10.4
• VSCode Version 1.77.3
• coverage.py 7.2.2

[ryanluker]

@merc1031 Thanks for submitting a ticket! At first glance, your understanding does look correct.

Are you able to provide the top of the file so that way we can see which coverage parser is being used? https://github.com/ryanluker/vscode-coverage-gutters/blob/master/src/files/coveragefile.ts#L22-L38

My first thought is that it might be using a parser that doesn't support partial coverage (afaik only the lcov format provides that and the python xml folks have been using COBERTURA).

[ssbarnea]

I can confirm the same bug and that is quite sad considering that Python is the most popular language and that coveragepy xml output format did not change format, still cobertura based. What is strange is that I do remember that this extension worked with python at some point, so I am not sure where the support got broken.

If anyone knows a workaround, please let me know.

I should mention that I also tried coverage lcov which produces a coverage.lcov file but apparently this extension fails to detect the file as coverage too. Running out of ideas...

[ryanluker]

I can confirm the same bug and that is quite sad considering that Python is the most popular language and that coveragepy xml output format did not change format, still cobertura based. What is strange is that I do remember that this extension worked with python at some point, so I am not sure where the support got broken.

If anyone knows a workaround, please let me know.

I should mention that I also tried coverage lcov which produces a coverage.lcov file but apparently this extension fails to detect the file as coverage too. Running out of ideas...

@ssbarnea Hmm sorry to hear the extension isn't working anymore for yeah, one other thing to try is adding the file specifically to the list of file names.

        "coverage-gutters.coverageFileNames": {
          "type": "array",
          "default": [
            "lcov.info",
            "cov.xml",
            "coverage.xml",
            "jacoco.xml",
            "coverage.cobertura.xml"
          ],
          "description": "coverage file names for the extension to automatically look for"
        },

There is also the option to specify a specific path to the file that might help as well.

         "coverage-gutters.manualCoverageFilePaths": {
          "type": "array",
          "default": [],
          "description": "take manual control over the absolute path to your coverage file(s). NOTE: this path must be the full absolute path, there is no support for the predefined path variables."
        },