Code Coverage Issues on Vagrant
Hello,
I am using PHPStorm on Windows and have a run configuration successfully executing PHPUnit tests on a Vagrant box. I have configured the path mappings in PHPStorm, so for instance V:\dev on Windows is mapped to /home/vagrant/dev on vagrant (running Ubuntu). All seems to be working fine except for the code coverage which always shows 0% for all files, and with no lines covered at all. I would like to understand why the coverage is not working when everything else is?
Here is some more information:
I am running PHPStorm version 2016.1.2. The vagrant box is running PHPUnit 3.7 and PHP 5.3.
If I run the unit tests with code coverage I see that PHPStorm executes the following command:
usr/bin/php -dxdebug.coverage_enable=1 /home/vagrant/.phpstorm_helpers/phpunit.php --coverage-clover /home/vagrant/.phpstorm_helpers/coverage/ProjectName_Run_Tests_Remotely.coverage --configuration /home/vagrant/dev/projectname/phpunit.xml.
I have confirmed that the ProjectName_Run_Tests_Remotely.coverage file exists and it appears to be loaded into the IDE if I go to the Tools->Show Code Coverage Data option.
I have also tried running the unit tests without PHPStorm code coverage, but instead adding my own coverage configuration to the phpuni.xml file. This generates a clover xml file, but if I load it into the IDE I still get 0% coverage.
Does anyone know why this isn't working? Is it because I'm running a really old version of PHPUnit? Are the clover xml files generated by that version incompatible with PHPStorm for instance?
Thanks,
James
请先登录再写评论。
Hi there,
Most likely the paths in generated coverage file are wrong (as in -- IDE is unable to map remote paths to local ones).
You can open that generated coverage file and see what paths it has there. Since you are loading it in IDE, it must contain "local" paths in order for IDE to display coverage info. But it most certainly will contain your remote paths .. which mean nothing (as in "path is outside of the project").
When you run "PHPUnit with Coverage" .. IDE should load that generated file and transform/replace remote paths into local ones. If you run coverage yourself .. you have to preform such replacements yourself.
Since PhpStorm shows 0% coverage .. this most likely means that it for some reason cannot do such path replacement correctly. It could be because invalid path mappings were specified (rather unlikely) ... or IDE cannot make such replacement (most likely). It may also happen if symbolic links are used somewhere in the path as xdebug (that provides coverage info) works with final/resolved paths only.
How did you define your PHP Interpreter in PhpStorm? Using Vagrant details?
----
Similarly sound recent thread: https://intellij-support.jetbrains.com/hc/en-us/community/posts/207103309-Code-Coverage-Report-0-Vagrant-Homestead
Hi Andriy,
Thanks for your help. Your comments caused me to take another look at the path mapping configuration and I have now successfully resolved the issue.
I had configured my interpreter using vagrant details and I had set up the path mappings for my vagrant box via the Settings->Languages & Frameworks->PHP->Servers page, but this was not the correct place for configuring unit test mappings. It turns out that the above was being used by a remote debug configuration I had running, and was the selected server for that configuration on the edit configurations page. However the unit test config does not let you select a server. Instead you have to go to Settings->Languages & Frameworks->PHP->PHPUnit, select the correct remote interpreter and then add the correct mappings to the 'Path mappings' field. Once I'd done that, the code coverage worked correctly!
Perhaps I missed the above instructions in the PHPStorm docs or perhaps they need improving slightly in that area.
Thanks,
James
Incidentally, it seems that some of the unit test configuration DOES actually use the server mappings, which is very confusing. For instance when you specify a configuration file for the PHPUnit, you specify using a local path and then PHPStorm converts that path to a remote path using available server mappings. This was working before I added mappings to the remote interpreter itself.
So short summary: make sure path mappings are specified on the server and interpreter settings pages.