CODEWITHSUNDEEP
phpsonarqubecode-analysisstatic-analysis
Kuba T
Kuba T

Reputation: 3083

Incorrect coverage with Sonarqube 6.2 and PHP plugin

Recently I've installed SonarQube to version 6.2. I've noticed that code coverage metrics have decreased dramatically. In coverage details I can see that files with @codeCoverageIgnore annotation or interfaces have uncovered lines. Looks like Sonar computed coverage by number of covered lines (from PHPUnit's xml output log) per all files in directory pointed by sonar.sources in sonar-project.properties.

Before installing SonarQube on my server I've been playing with version 6.1 running on official Docker image and it's been was working like a charm.

I've found no open issue/ticker/similar question related to such problem so maybe I'm doing something wrong.

Details:

phpunit --coverage-clover=build/phpunit.coverage.xml --log-junit=build/phpunit.log.xml

Upvotes: 1

Views: 672

Answers (1)

G. Ann - SonarSource Team
G. Ann - SonarSource Team

Reputation: 22824

Your coverage numbers dropped with SonarQube 6.2 and SonarPHP 2.9.2 because that combination of versions (and above) feeds "executable lines" data so that coverage can be "forced to zero" on files that aren't included in coverage reports.

I.E. SonarQube 6.2 is designed to give you a more accurate idea of what your true coverage ratio is. Before that, it had to rely on the list of files and lines fed by the coverage engine and many coverage engines simply ignore (i.e. don't include in their reports) files where none of the lines are tested. Now the code analyzer, SonarPHP in this case, is feeding a list of executable lines for all those files ignored by your coverage engine, so you have a larger ratio of uncovered lines, and thus a drop in the coverage percentage.

If you want your coverage numbers to go back to what they were, you have two choices:

  1. write more tests! ;-p
  2. add exclusions for the uncovered files

Upvotes: 1

Related Questions