Sonar coverage mismatch vs istanbul

[jamessetaro]

I ran across sonar integration issue as well. Copied from here http://stackoverflow.com/questions/28806209/how-to-change-the-format-of-the-lcov-report-executed-by-karma

Unfortunately, the Sonarqube JavaScript plugin only considers the lines that start with SF:, DA: or BRDA: (cf LCOVParser).

Due to that, the LCOV HTML report (made by Istanbul) gives me a higher code coverage than Sonar on the same data.

Is there a way to change the format of the lcov.info generated?

If I look in Istanbul code, I can imagine the meaning of the different labels:

BRF, BRH, BRDA are for branches. FN, FNF, FNH, FNDA are for functions. LN, LF, LH are for lines. *F is the total, while *H is the covered information. The difference between the Istanbul and Sonar coverage seems to be due to the fact that the latter completely ignores the Functions and Branches coverage.

Any idea to solve that?

[MartinKei]

I have the same problem.

@jamessetaro Did you manage to solve the problem?

[MartinKei]

@jamessetaro

I learned the following things:

• I have to make absolute paths relative. Either you use the not yet published version of karma which supports a new parameter your you do it via sed. (e.g. with sed s'|^SF:.*/src/|SF:src/|' ./coverage/coverage_absolute_paths.lcov > ./coverage/coverage.lcov)
• I have adjusted the rules of SonarQube project config. (I had to exclude **/*.spec.ts, **/*.module.ts, **/*.interface.ts and **/*.type.ts files)

Still not 100% the same but now it's not that far apart.

[jayakrishnankk]

We also have the same problem. We also implemented the same approach that @MartinKei has proposed. We were able to bring down the difference in coverage percentage. However, there is still a difference of +10%. SonarQube: 35% and Instanbul: 46%

Whom should we report this to in order to get this fixed ?

[shierro]

@jayakrishnankk my theory is that: not all files you want to ignore are ignored can you verify if all your test files are ignored? example in my case: sonar-project.properties

sonar.exclusions=src/**/*.spec.js
sonar.test.exclusions=src/**/*.spec.js

and here is some logs

INFO: Language is forced to js
INFO: Index files
INFO: Excluded sources:
INFO:   src/**/*.spec.js
INFO: Excluded tests:
INFO:   src/**/*.spec.js
INFO: 7 files indexed
INFO: 2 files ignored because of inclusion/exclusion patterns

i know i have 2 spec files and sonar-scanner was able to ignore 2 files & generate accurate result.

[thomassittig]

hello everyone, does someone has news on this issues? we have a similar issue in our project. but the gap is not that big (~2%), just big enough to get on our nerves.

[shaikhjishan37]

by sonar exclusion property we can only exclude files but istanbul also ignores functions from coverage, i am facing same problem. does anyone found solution

[naveenb29]

similar issues , only HTML I see that we have 70% coverage but on sonar , see only 4%.

[cmacdonnacha]

I'm a bit confused as to why we need to specify sonar.exclusions when we have already excluded those files in the Istanbul report? I don't see much point having to have exclusions in 2 places.

[masterfaka]

Luckly excluding **/*.spec.ts from our pom.xml file did the trick :D

• thanks @everyone for the ideas :)
• Also note that comparing what files sonar(coverage) sees with istambul , "by eye" as starting point, might also help.