PHPUnit Remote Test Runner Failing

Whenever an error is triggered by a unit test, I get the following error while running the tests remotely

Catchable fatal error: Argument 5 passed to PHPUnit_Framework_Error::__construct() must be an instance of Exception, array given

This is triggered by _intellij_phpunit_launcher.php on line 333.   There is a bug report with a similar problem here: http://youtrack.jetbrains.com/issue/WI-14401#tab=Comments.  This problem occurs regardless if you were trying to catch an error exception.  If you just have an error caused by say a bad file path, you will get the issue above and will not be able to see the actual error message which makes it pretty hard to write any code.  I end up having to run a test runner manually outside of phpstorm and display the results in a browser to get the actual error message.

The fix is actually rather simple though, and can be done by changing a few lines in _intellij_phpunit_launcher.php.   Since the fix is not targeted until version 6, I would like to know if there is a way for me to do any of the following:

- Modify the _intellij_phpunit_launcher.php script that is sent by phpstorm.  I cannot find this file on the system though and I assume it is embedded as a resource somewhere where I cannot touch it.

- If the above is not an option, is it possible to create a readonly version of this file on the server that cannot be overwritten by phpstorm and place it where phpstorm attempts to upload it?

- Specify a different test runner but still be able to see the test results and debug the stes from within phpstorm.

4 comments
Comment actions Permalink
Modify the _intellij_phpunit_launcher.php script that is sent by phpstorm.  I cannot find this file on the system though and I assume it is embedded as a resource somewhere where I cannot touch it.

The file is located in PhpStorm_INSTALL_FOLDER/plugins/phplib/php.jar (you can open it with WinRAR or similar programs -- it's normal ZIP archive). The file you are after is located in "scripts" folder. You can safely edit it and then save it back into jar file. Obviously, if you install newer version, you will need to do it again.

0
Comment actions Permalink

Excellent, thanks much.

Do you want me to forward you the code changes to fix this after I test it out?

Secondly, I noticed that the test runner ignores the 'convertErrorsToExceptions' setting when set in the xml config file.  I know it is loading the file since I am specifying my bootstrap.php from there, but that setting gets ignored, and I assume a lot of others.

0
Comment actions Permalink
Do you want me to forward you the code changes to fix this after I test it out?

I'm not a dev .. but you can attach changes (patch or whole file)  to this thread (in case devs want to look at it) or leave a link to online version (e.g. github etc)

Secondly, I noticed that the test runner ignores the 'convertErrorsToExceptions' setting when set in the xml config file.  I know it is loading the file since I am specifying my bootstrap.php from there, but that setting gets ignored, and I assume a lot of others.

I would assume this one: http://youtrack.jetbrains.com/issue/WI-9369

P.S.
Check this thread -- maybe you will find something useful there: http://devnet.jetbrains.net/thread/439215?tstart=60

0
Comment actions Permalink

I got it to work thanks to the info you provided.



Original

throw new $exception($errstr, $errno, $errfile, $errline, $trace);

Fix
throw new $exception($errstr, $errno, $errfile, $errline);



This is on line 333 in phpunit-launcher.php.

As far as the xml configuration issue, it is not related to the other issues you posted.  The file is definitely being located and read as that is where the bootloader is specified.  However, some of the settings are being ignored.  While looking at this phpunit-launcher.php code I see that there is a global variable called $doConvertErrorToExceptions and it is set explicitly.  I don't think this is a huge issue though as I assume it would take a lot of rewriting of that launcher code to get it to work, and I can't imagine demand for that would be high.

Also, the above patch solves the test case posted in http://youtrack.jetbrains.com/issue/WI-14401#tab=Comments
0

Please sign in to leave a comment.