I'm really at loss on what's going on - it all begun with PHPUnit error of Error: No code coverage driver is available
when trying to run test coverage report and ended with me debugging to a replicable set described below. But to set the stage - I'm using Laravel 5.5, Xdebug 2.5.5, PHPUnit 6.5.5. My test code that illustrates the issue:
<?php
use Tests\TestCase;
class A extends TestCase
{
public function testA()
{
echo( get_cfg_var('cfg_file_path')); exit;
}
}
outputs C:\Users\xxx\AppData\Local\Temp\7598.tmp
compare it to this code which outputs the correct php.ini path:
<?php
use PHPUnit\Framework\TestCase;
class A extends TestCase
{
public function testA()
{
echo( get_cfg_var('cfg_file_path')); exit;
}
}
outputs: C:\server\php\php.ini
How can it be? How can loaded php.ini file change dependant upon the executed code? Better yet - how can my correct php.ini file (that has xdebug enabled) be loaded, instead of this imposter?
In both cases tests are launched using phpunit tests\unit\a
Folder structure is:
Laravel Project
└───tests
└───Unit
└───A.php
We've tracked it down to an issue with Composer's XdebugHandler.php::writeTmpIni
function located in vendor\composer\composer\src\Composer\XdebugHandler.php
.
Apparently during App initialization a separate php
process is spawned with temporary php.ini
, and to that php process is the test passed to, but why it is done so is currently beyond me.
Will flag it up on Laravel's bugtracker in regards to what to do with this.
The dependancy that adds Composer, as a package (in my case) is larapack/hooks
, which in itself is a dependancy for larapack/voyager-hooks
, which in itself is a dependancy for Voyager.
As far as a I know, during the initialisation of the Laravel application this behaviour shouldn't be triggered (why initialise a dependency that is not required, at least explicitly). Why does Composer trigger itself at that stage is beyond me as well.
The solution we've applied is to add:
<php>
<env name="COMPOSER_ALLOW_XDEBUG" value="1"/>
</php>
in the phpunit.xml
file
I've now submitted this as an issue: https://github.com/laravel/framework/issues/22782
Per discussion on GitHub it's caused by the change in Laravel 5.5, in regards to handling service providers (https://laravel.com/docs/5.5/packages#package-discovery). How it gets updated, I don't know - to me it's a change between 5.4 and 5.5 that deserves a note in the upgrades (but please, read the discussion that happened on Github and make your own decision about the matter); to be honest, reporting this issue left a sour taste in my mouth and I won't be pursuing it further.
I've also opened an issue on larapack/voyager-hooks
in regards to handling service providers discovery introduced in 5.5 - https://github.com/larapack/voyager-hooks/issues/16
This has now been fixed in larapack/hooks:v1.0.3
I had some other issues seemed weird to me before. It seem you are using Windows machine as your dev. I am not sure about your php installation. But what happened to me I had a lot of different instances of apache, php, phpunit, nginx, mysql located all around different folders.
My point is it looks like you have many php installed on your machine. And for some reason different php interpreters are in use for 2 cases described in OP.
I can be wrong and still have no response on my comment about commands and folders you use to execute both tests.
But you can just output
echo PHP_BINDIR;
in both tests to be sure that same php interpreter is in use in both cases.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With