41

I've configured Karma to report the coverage of my JavaScript code. Here is the part of the configuration in the karma.conf.js file:

coverageReporter: {
  reporters: [
    {
      type: 'html',
      dir: 'build/karma/coverage'
    },
    {
      type: 'lcov',
      dir: 'build/karma/coverage',
      subdir: '.'
    },
    {
      type: 'cobertura',
      dir: 'build/karma/coverage'
    }
  ]
},

My lcov.info file has the following format:

TN:
SF:./app/scripts/app.js
FN:16,(anonymous_1)
FN:26,(anonymous_2)
FNF:2
FNH:1
FNDA:1,(anonymous_1)
FNDA:0,(anonymous_2)
DA:2,1
DA:20,1
DA:29,0
DA:34,0
LF:4
LH:2
BRF:0
BRH:0
end_of_record

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?

Romain Linsolas
  • 79,475
  • 49
  • 202
  • 273
  • Have you considered using the karma-sonarqube-unit-reporter: https://www.npmjs.com/package/karma-sonarqube-unit-reporter – DevDig Nov 07 '16 at 08:58
  • We ran into this as well and then ditched the javascript plugin for running the scripts directly. https://github.com/carsdotcom/gulp-sonar Is a nice plugin to work into your gulpfile. It might not work for every situation but solved this problem for us. – devilfart Dec 04 '16 at 23:26
  • 1
    We had a similar issue where the sonar was expecting an absolute file path to calculate the coverage. Our workaround was to add a build task that modified the lcov.info to add the absolute path prefix on the SF: lines – claya Feb 04 '17 at 00:56
  • Did you make it work? I stuck with the lcov import which could not resolve file path, explained here https://stackoverflow.com/questions/51878860/sonarqube-and-lcov-report-could-not-resolve-file-paths – Murali Murugesan Aug 16 '18 at 14:13
  • @claya, It would be helpful if you update the build task details. So I can follow the same to see if it works. We are using team city – Murali Murugesan Aug 16 '18 at 14:17
  • Yeah we also had absolute/relative path issue. So we just added a one-liner "sed" script which fixes paths after tests were ran (and before Sonar). – Serhii Matrunchyk May 25 '22 at 22:08
  • Btw, they have already fixed branches: https://github.com/SonarSource/SonarJS/commit/d60a53eefc41f7c6a620b8c8d30a89fa590d0809 – Serhii Matrunchyk May 25 '22 at 22:29

1 Answers1

4

You could run a script that does: cat lcov.info | egrep "^(SF|DA|BRDA):" > lcov.info.new; mv lcov.info.new lcov.info.

With that I get:

SF:./app/scripts/app.js
DA:2,1
DA:20,1
DA:29,0
DA:34,0
Dorian
  • 22,759
  • 8
  • 120
  • 116