Lines to cover change when I add a coverage.xml file

SonarQube
,
1

Hi,

First of all, here is what I’m using:

  • Sonarqube: Developer Edition - Version 9.3 (build 51899)
  • Scanner: 4.6.0
  • Language: PHP
  • Test and Coverage: PhpUnit 9.5.20
  • sonar-project.properties:
sonar.sources=.
sonar.exclusions=**/vendor/**/*,**/dist/**/*,**/node_modules/**/*,resources/lang/**/*,database/migrations/**/*,tests/**/*,**/*.yml,**/*.yaml

The issue is that the lines to cover of a project change when I add de coverage.xml to the sonar-project.properties file of my project like this:

sonar.php.coverage.reportPaths=tests/Unitary/coverage/coverage.xml

I really don’t know if it’s really an issue or just an expected behavior I don’t understand. I experienced other dramatic changes in the LoC with other things like rising a version of a thrid party library on my composer.json but I think all are related to the coverage.xml file.

When I add the coverage results to the tests, the lines to cover metric rises, in this particular case, from 6229 lines to cover and 0 covered lines (no coverage.xml added to the scanner) to 11054 lines to cover and 2761 covered lines (with the coverage.xml added to the scanner). I want to remark that the only change is add that particular line I said before to the sonar-project.properties

Any ideas?

Thank you!

2

Hi,

So FYI, SonarQube 9.6 was announced on Monday. I don’t think and upgrade will make a difference though. I don’t remember any recent work in this area.

Could you do a little sleuthing and see if you can figure out where the increase in coverable lines is coming from? Yes, I know that’s why you contacted us, but to diagnose this we need some understanding of which files/lines are added to the calculation when you add coverage.xml.

Here’s my understanding of how that Lines to Cover calculation works. For each file, if it’s included in the coverage report, then we just use whatever the coverage engine said. If it’s not in the coverage report and analysis has calculated Executable Lines for it, then we use that number.

So I’m guessing that coverage.xml includes some files that analysis didn’t previously recognize as coverable. But we need more data to go any further.

 
Ann

3

Hi @ganncamp, thanks for your quick response.

I’ll take a look at SonarQube 9.6 but, as you say, I also don’t think the upgrade will make any difference.

I’ve been digging a bit in the coverage.xml file. Here are the general metrics found in the xml file.

    <metrics files="511" loc="45152" ncloc="34141" classes="465" methods="2795" coveredmethods="1368" conditionals="0" coveredconditionals="0" statements="8216" coveredstatements="1393" elements="11011" coveredelements="2761"/>

So comparing that with the numbers I gave you before, the coveredelements attribute matches with the Covered Lines value in SonarQube, which makes sense. The elements attribute is close to the new Lines to Cover value in SonarQube but not exactly the same, there is a difference of 43. I’ve seen that this value is “loc - ncloc”, that gave me the idea that maybe the difference of what is happening is in what SonarQube and PHPUnit consider as coverable. I’ve also checked the files in the coverage.xml file and all files are reported in SonarQube and no new file is added.

Comparing a random file with and without the coverage.xml file in the analysis of SonarQube I’ve noticed that it does not mark the method header as not covered with a red mark on the left. But, if I add the coverage file to the analysis, the method is marked in green as covered. Could that be one a possible source for the difference? Does SonarQube take methods and classes by its own as something coverable?

Answering myself… I just noticed in SonarQube in the File measures for the same file, with and without coverage, the results are different. So, SonarQube and PHPUnit don’t have the same concept of “what to cover count”. Just to explain it, I have a class with a getter and a setter method for an attribute of the class. Without the coverage.xml the lines to cover in SonarQube are 2, the 2 statements of the methods. With the coverage.xml the lines to cover are 4, the 2 statements of the methods and the 2 method headers.

So, with the coverage.xml the Lines to Cover transforms into the covered elements value that includes methods and statements and SonarQube just takes statements into account in its own analysis.

With all the previous in mind, is there any config value to alter this behaviour? I looked in the PHPUnit configuration and SonarQube configuration but didn’t see anything. Is this a bug or something that needs a configuration option to manage its behaviour?

Thank you!

4

Hi,

Did you follow the link I gave in my previous answer about Executable Lines? It really will answer most of your questions.

 
Ann

5

Hi,

Sorry @ganncamp I didn’t see the link when I first read your response and started digging to the coverage.xml file as you seggested. Well, after reading that link I understand what is happening with the coverage and lines of code.

Thank you

1 Like