Invalid clover.xml

🐛 Bug Report

The generated clover.xml differs from the other reports.

To Reproduce

src/foo.js

function foo(a,b) {
    if (a === 0) {
        a = 1
    }
    if (b === 0) {
        b = 1
    }
    return a
}

module.exports = {foo}

src/foo.test.js

const { foo } = require("./foo")

it('tests condition for a', () => {
    expect(foo(0,0)).toEqual(1)
    expect(foo(2,0)).toEqual(2)
})

Run

$ yarn jest --coverage

Expected behavior

Report partial coverage for if (b === 0) { and full coverage for if (a === 0) {.

Actual behavior

Correct report on the cli, but wrong report in coverage/clover.xml

      <line num="2" count="2" type="cond" truecount="2" falsecount="0"/>
      <line num="5" count="2" type="cond" truecount="1" falsecount="1"/>

Link to repl or repo

https://repl.it/repls/RustyWanVariety

envinfo

System:
    OS: Linux 5.4 Debian GNU/Linux 9 (stretch) 9 (stretch)
    CPU: (4) x64 Intel(R) Xeon(R) CPU @ 2.30GHz
  Binaries:
    Node: 12.16.3 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.9.0 => 24.9.0 

I got the same result with 26.1.

[jordanleven]

I noticed this as well - FWIW, the coverage-final.json file appears to be correct (in case you’re looking for a stop gap for reporting coverage to something like Codecov or Code Climate).

[coreyfarrell]

@SimenB it wouldn’t surprise me if the istanbul clover report is broken, I don’t think it is maintained. I wouldn’t know if a clover report is correct or not. Given the lack of understanding by istanbuljs and lack of automated testing I’m not sure this situation will improve. Even accepting patches from the community is difficult due to lack of testing / understanding, I have no way of knowing if a patch is correct (doesn’t cause regressions for other clover users). The cobertura and teamcity reports are also in the same situation. Fixing mixed up branches might be a simpler fix but it’s hard to know. Assuming jest is not producing broken source-maps then I don’t see how this could be the fault of jest.

My personal recommendation for output to other systems is to use the lcovonly report to produce lcov output then use a tool provided by the other system to read the lcov. I don’t know these other systems but assume some tool must exist for reading lcov files (likely how they would read coverage from C projects built by gcc).