we are running SonarCloud for our PHP Spryker project and sadly we are not happy about our coverage reports or better said that we would like that the PHPUnit “codeCoverageIgnore” is respected.
As far as our tests go and as we understand the manual SonarCloud only uses the excludes here:
sonar.coverage.exclusions=/*Interface.php,/DependencyProvider.php,/*Factory.php,/Client.php,/*Stub.php,/Facade.php,**/.twig,**/.ts,src/Generated/*
If we exclude anything via PHPUnit the data is excluded from the report and SonarCloud will now evaluate the missing files as totally uncovered.
I know we can include the ignored files but don’t believe this would be a solution.
Why is SonarCloud checking the covered files at all again and doesn’t just trust on the PHPunit report completely? I believe that would be a better solution. So can we set it up like this? Are we missing anything?
Hi Ann, thanks for your answer
But sorry I don’t really get the usage of this.
" With the introduction of executable lines, we’re able to take files omitted from the coverage reports into account to show the real coverage numbers."
Well okay but why? So you do not trust PHPUnit to do a really and meaningful report if the files or methods are omitted?
But still you do not run a real coverage report by using xdebug or something yourself?
I am reading the blog post several times now and it seem’s I am still missing the point about this.
Right now I would say: Can you please let use turn this off and trust PHPUnit? Otherwise we don’t want to use SonarCloud for code coverage. Which makes me a bit sad.
I will discuss this with my colleagues and maybe they can share some insight.
This isn’t specifically about PHPUnit. What we found is that for some coverage engines if you don’t have any coverage for a file, that file is just ignored in the report.
