Asked  1 Year ago    Answers:  5   Viewed   16 times

I created a phpunit test file , when I try to run it via phpstorm, I get the message:

Unable to attach test reporter to test framework or test framework quit unexpectedly 

seems the following command is executed:

 /usr/local/bin/php /private/var/folders/4b/qrnw7nbd6llgmhrss5rf1_880000gt/T/ide-phpunit.php  --configuration /Users/Shared/sites/pac/app/app/phpunit.xml.dist BackendControllerTest /Users/Shared/sites/pac/app/modules/Pac/Backend/Tests/Controller/BackendControllerTest.php
Testing started at 23:22 ...

Process finished with exit code 0

when i execute this via command line , i get much more output

PHPUnit 3.6.11 by Sebastian Bergmann.


Tests: 2, Assertions: 2, Failures: 1.

seems phpunit isn't executed in phpstorm? shouldn't there be some sort of error message instead of finishing with exit code 0? Paths to php & phpunit (same) in phpstorms configuration should be ok (both installed via homebrew in /usr/local/bin, path added to phpstorm)

osx 10.7.4 php 5.3.14 PHPUnit 3.6.11

Thanks for helping me!



On Mac OS X environment variables available in Terminal and for the normal applications can be different, check the related question for the solution how to make them similar.

Note that this solution will not work on Mountain Lion (10.8).

Saturday, May 29, 2021

You should point to your vendor/autoload.php at Settings | PHP | PHPUnit when using PHPUnit via Composer.

This blog post has all the details (with pictures) to successfully configure IDE for such scenario:

Related usability ticket:

P.S. The WI-18388 ticket is already fixed in v8.0

Thursday, April 1, 2021

PhpStorm has special integration script to run PHPUnit tests (all messages/progress indicators are transferred into GUI part where you can easily see what tests have passed and what did not etc).

PhpStorm's console does not support ANSI colors -- and related tickets.

But you can install Grep Console plugin and it will add support for ANSI colors (needs to be activated in Settings). I have tried it with PHPUnit and it worked -- not everything was colored (some of the codes were not recognized, but most worked). You can contact plugin author with not working parts if desired.

Saturday, May 29, 2021

You need to make sure that the newly installed php command is executed, not the default one.

Add the folder where the correct php binary resides as the first item to the $PATH environment variable.

Saturday, May 29, 2021

tl;dr Apple broke version_compare by naming PHP 7.3.22-(to be removed in future macOS) in Big Sur. Installing another version of PHP fix this.

I found the answer to my issue. It is indeed a MacOS issue, related to the built in version of PHP in MacOS Big Sur.

After quite some debugging (on another project using PHPUnit 8), I endend up here :

    private function satisfiesPhpVersion(DOMElement $node): bool
        $phpVersion         = PHP_VERSION;
        $phpVersionOperator = '>=';

        if ($node->hasAttribute('phpVersion')) {
            $phpVersion = (string) $node->getAttribute('phpVersion');

        if ($node->hasAttribute('phpVersionOperator')) {
            $phpVersionOperator = (string) $node->getAttribute('phpVersionOperator');

        return version_compare(PHP_VERSION, $phpVersion, (new VersionComparisonOperator($phpVersionOperator))->asString());

When looking at the last line of PHPUnit code above (and since both $node->hasAttribute('phpVersion') and $node->hasAttribute('phpVersionOperator') return false), the return statement can be simplified to:

version_compare(PHP_VERSION, PHP_VERSION, '>=')

Now, because the version of PHP that ships with MacOS got deprecated in Big Sur, Apple renamed the version to 7.3.22-(to be removed in future macOS). This is what caused the issue, as the above code now become :

version_compare("7.3.22-(to be removed in future macOS)", "7.3.22-(to be removed in future macOS)", '>=')

Which return false instead of true.

A simple way to test :

$foo = version_compare("7.3.22-(to be removed in future macOS)", "7.3.22-(to be removed in future macOS)", '>=');
var_dump($foo); // bool(false)

$bar = version_compare("7.3.22", "7.3.22", '>=');
var_dump($bar); // bool(true)

That is probably because, as explained in the official PHP Documentation...

The function first replaces _, - and + with a dot . in the version strings and also inserts dots . before and after any non number so that for example '4.3.2RC1' becomes '4.3.2.RC.1'. Then it compares the parts starting from left to right. If a part contains special version strings these are handled in the following order: any string not found in this list < dev < alpha = a < beta = b < RC = rc < # < pl = p. This way not only versions with different levels like '4.1' and '4.1.2' can be compared but also any PHP specific version containing development state.

Note that pre-release versions, such as 5.3.0-dev, are considered lower than their final release counterparts (like 5.3.0).

...the naming scheme of Apple is probably treated as a pre-release version inferior to itself instead of being equal to itself.

So the fix would to overwrite the php version, which can't be done globally as far as I know. Installing another version of PHP using Homebrew seems the easiest solution

Thursday, December 16, 2021
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :