I get the following exception while using Idea 13.1.3 with PHPUnit 4.5.0. In some other threads I have seen it was a bug but I this seems to be a problem with latest version also.
Testing started at 17:06 ...
Fatal error: Class IDE_PHPUnit_Framework_TestListener contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (PHPUnit_Framework_TestListener::addRiskyTest) in /private/var/folders/yc/cc0z8db95hx4l_d0fvtrx2yxsjjh3x/T/ide-phpunit.php on line 504
Call Stack:
0.0014 854704 1. {main}() /private/var/folders/yc/cc0z8db95hx4l_d0fvtrx2yxsjjh3x/T/ide-phpunit.php:0
Variables in local scope (#1):
$PHPUnitVersionId = *uninitialized*
Process finished with exit code 255
Found from IntelliJ forum that IntelliJ 13 is only compatible with PHPUnit 3.x.
However instead of downgrading, I managed to patch the framework itself for now in this way.
go to /plugins/php/lib
make a backup of php.jar
Use whatever tool you have to open the file, usually zip or other compress tools or under ubuntu the file roller.
Go to scripts/phpunit.php
Modify it, searching for the "IDE_PHPUnit_Framework_TestListener" class and adding there the following line:
public function addRiskyTest(PHPUnit_Framework_Test $test, Exception
$e, $time) {}
save the file and update the php.jar
The easy part...
Usually when migrating a ZF1 application from built-in auto-loading to composer based auto-loading (which is strongly recommended for deploying on CloudControls Pinky stack) you just need to take some simple steps:
Create a composer.json file and require Zend Framework (e.g. latest release from version 1.12) with:
{
"require" : {
"zendframework/zendframework1" : "1.12.*"
}
}
Install composer dependencies via CLI with:
composer install
Update your .gitignore file and add:
vendor/*
Recursively delete current ZF folder from your library path (e.g. ./library):
rm -r library/Zend
Include composer autoloader in your index.php before any usage of Zend_ classes by adding:
$loader = include 'vendor/autoload.php';
Remove every now obsolete ZF related require or require_once statements from your index.php - e.g. this is not needed anymore:
require_once 'Zend/Application.php';
Once you are done with the above changes you commit and push via git as normal and then you deploy the new version on CloudControl via CLI (where APP_NAME and DEP_NAME here refer to your app and deployment names):
cctrlapp APP_NAME/DEP_NAME deploy
You will notice that cctrlapp prints out some information about resolving composer dependencies and finally initiates the deployment of the new version. To check whether it is done you can run:
cctrlapp APP_NAME/DEP_NAME log deploy
Ok, deployment log looks fine – nice – let's open the browser!
What the f***! Internal server error? Why?? Everything worked well with the local LA(M)P stack!!!
The tricky part...
Fortunately CloudControl gives us access to the error logs as well ...
cctrlapp APP_NAME/DEP_NAME log error
Shouldn't be too hard to find out what's wrong here.
But ... err ...
8/1/14 5:23 AM error [error] [client ] FastCGI: incomplete headers (0 bytes) received from server "/app/php/box/php-fpm"
8/1/14 5:23 AM error [error] [client ] (104)Connection reset by peer: FastCGI: comm with server "/app/php/box/php-fpm" aborted: read failed
As the above error messages are not helpful at all we first need to track down this very bug. And this can indeed be tricky! We can google a bit. We can try something. We can then redeploy. We can google a bit more. We can try another thing. We can then redeploy again. We can google another time. We can try out every other thing. We can ... but do we want?
Luckily the Pinky stack offers another way to speed things up (which Luigi does not all). While it still incorporates cumbersome manual debugging at least we can save some time – go to your CLI and execute:
cctrlapp APP_NAME/DEP_NAME run bash
CloudControl now instantiates a new container for us and gives us SSH based shell access to it. As the documentation says everything should be as it is inside our deployment boxes:
The distributed nature of the cloudControl platform means it's not
possible to SSH into the actual server. Instead, we offer the run
command, that allows you to launch a new container and connect to that
via SSH.
The container is identical to the web or worker containers but starts
an SSH daemon instead of one of the Procfile commands. It's based on
the same stack image and deployment image and does also provides the
Add-on credentials.
Let's see if we can find out more (from inside the container):
cd code/public
php index.php
Hmm ... nothing reported here ... and ... nothing reported at the logs?! What the hell?!!
So, there seems to be a difference between the web and the run containers – and there is!
To find this out I started by editing the index.php right away:
vi index.php
And after a while I finally got to reproduce at least another error:
8/1/14 8:55 AM error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Fatal error: require_once(): Failed opening required '' (include_path='/srv/www/code/vendor/zendframework/zendframework1/library:/srv/www/code/library:.:/usr/share/php') in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...
8/1/14 8:55 AM error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Warning: require_once(/srv/www/code/vendor/zendframework/zendframework1/library): failed to open stream: No such file or directory in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...
Looks like some file is missing – maybe related to auto-loading – shouldn't be too hard to fix it.
But wait, what's that: Failed opening required ''? Sure you fail to require nothing you stupid code you!!
Well ... when looking at the respective ZF library files you won't find anything wrong there. The include paths seem to be correct as well – and yes, the files are present – composer managed both things correctly.
It's a PHP bug!
To be more precise it is a bug with PECL APC which affects Pinky's current versions of PHP 5.4.30 / APC 3.1.13 - see:
https://bugs.php.net/bug.php?id=62398
And that's exactly the difference between the run and the web containers as php.ini option apc.stat is set to 0 (off) for the web containers and 1 (on) for the run container.
tl;dr
Clone the CloudControl Pinky PHP buildpack from GitHub:
git clone https://github.com/cloudControl/buildpack-php.git
Copy all files from this repository and add them to your project root folder at:
.buildpack/php
Edit .buildpack/php/conf/php.ini and set:
apc.stat = 1
Commit, push, deploy and enjoy!
Notes:
Keep in mind that this is just a workaround as APC stat does not need to be activated in such an environment (where the stack is recreated on deploy) and it slows down execution. See the PHP docs:
On a production server where the script files rarely change, a
significant performance boost can be achieved by disabled stats.
Thanks:
Finally I'd like to thank Dimitris and Mateusz from CloudControl for general advises – though I need to find out on my own what was going on here. Furthermore I want to thank #BullfrogBlues and #Thierry_Marianne here at Stack Overflow who tried to answer another questioners thread dating back to November last year, which finally pointed me to look for APC related issues.
I am very new to NetBeans and I just wanted to run a Code Coverage teston my code developed earlier. I do not know what I am doing wrong.
I am using NetBeans 7.3.1 with Wamp Server 2.4, installed PHPUnit and Skeleton Generator through PEAR, and set those files in NetBeans settings.
I made the project using an existing sources. Running in my browser seems OK. I can even debug with XDebug.
But when I right click on the project name and "Test", it says "No tests executed.(0.0 s)" in the Test Result window, and this in the Output window:
PHPUnit 3.7.23 by Sebastian Bergmann.
Configuration read from C:\wamp\www\test\configuration.xml
Time: 141 ms, Memory: 2.00Mb
No tests executed!
Generating code coverage report in Clover XML format ... done
I tried running test on a PHP file, it returns an information dialog box "Test file for the selected source file was not found."
I right clicked on the PHP file, and selected "Tools->Create PHPUnit tests", it returns a warning dialog box "Tests were not generated for the following files: (file name) Review the log in Output Window." but nothing was changed in the Output window.
I generated PHPUnit Bootstrap and XML Configuration, but they did not help.
I wished I can provide screenshots, but I cannot. I am trying to be specific as possible.
I appreciate any help.
I got this error too.. I also got this in the Output tab
Fatal error: Class 'package\path\Tests\TestCase' not found in project\path\package\path\Tests\ClientTest.php on line 25
Here, TestCase is the subclass of PHPUnit_Framework_TestCase and that, along with the current test file is in a different directory structure than the source files. So, in my case, it was a path issue.
Something I noted is I need to add a bootstrap file to include files in the test path and the source path to the runtime.
This bootstrap could be generated by NetBeans. See instructions here: https://netbeans.org/kb/docs/php/phpunit.html#project-specific-configurations
I of course, had another bootstrap.php (added by another developer). I only had to link the bootstrap like follows,
Good luck!
PHPUnits message:
No tests executed!
just means that no tests were found. This can have multiple reasons:
First of all, if there are no tests, no tests are executed.
But it is also possible that there are tests, but the configuration says to skip those (for example some tests are grouped into a group named slow and the configuration XML says to exclude slow from being run).
For your case this most certainly is a configuration issue. I'm not fluent with Netbeans but as you can successfully execute PHPUnit already, that part of your setup looks working.
Next step is to find out when you invoke the test-runner where it looks for tests. It might just be that the tests directory is missing or not specified. E.g. check which configuration is in configuration.xml for example and compare that with the documentation to double-check all settings.
This is not a very concrete answer and somebody who is more fluent with Netbeans might help more, however as you'er not showing further screenshots, this is my honest best bet how to go on with trouble-shooting and why.
Seems I am getting closer to the solution. I found out the problem is not in the configurations, but in the code itself.
I do not know if this is a silly problem, but seems the test only accepts PHP codes written in OOP. I tried making another file with a class and I can make test file out of it with no problem. At least I can see the test result changes from "No test executed" to "No test passed, 1 test skipped"
My codes are written for months without OOP and I know nothing about it at all. Does this mean I have to rewrite all of them again?
It will happen when you put an assertion in a constructor of your test class and this assertion fails.
Then you will see only the warning 'No tests executed!' (not very helpful) but i suppose one should not put assertions in the constructors (this is in phpunit 4.1~).
for it was because my test names were not starting with 'test'
I've browsed through similar problems on SO, but to no avail. I'm running PHP 5.3.6 and phpunit version 3.6.10. When attempting to execute a simple test:
require_once 'PHPUnit/Framework.php';
class UserTest extends PHPUnit_Framework_TestCase {
}
I receive the following error:
PHP Fatal error: require_once(): Failed opening required 'PHPUnit/Framework.php'
(include_path='.:/Users/username/pear/share/pear:/usr/lib/php/pear/:/Users/username/pear/share/pear/PHPUnit') in ...
When reinstalling PHPUnit, I'm not sure if the install location was duplicated, but it appears that when running which phpunit, the path is: /usr/bin/phpunit. However, it appears to also be installed in /Users/user/pear/bin/phpunit.
I've tried updating all channels and reinstalling PEAR and PHPUnit, but the problem still exists. I'm running on OSX Lion. Any help would be greatly appreciated.
Just remove the line
require_once 'PHPUnit/Framework.php';
and everything should work.
You don't need to include/require anything PHPUnit related since (at least) PHPUnit 3.6 any more and you can't include that file because it doesn't exist any more in the distribution.
The phpunit runner will take care of bootstrapping everything that is needed by PHPUnit :)
As others pointed out, Framework.php is not required anymore.
But in any case if you already have too many test files written and having the include statement, then fixing them going to be a cumbersome task. Which was the case I had to face.
If a quick workaround is needed, create an empty Framework.php file. That will resolve the problem.
Create an empty file named Framework.php under your PHPUnit directory. (eg: at: /usr/share/php/PHPUnit/Framework.php).
sudo touch /usr/share/php/PHPUnit/Framework.php
When a PHPUnit test fails normally on my dev box (Linux Mint), it causes a "Segmentation Fault" on my Continous Integration box (Centos). Both machines are running the same version of PHPUnit. My dev box is running PHP 5.3.2-1ubuntu4.9, and the CI is PHP 5.2.17. I'd rather leave upgrading the PHP as a last resort though.
As per this thread: PHPUnit gets segmentation fault
I have tried deactivating / reinstalling Xdebug. I don't have inclue.so installed.
On the CI box I currently only have two extensions active: dom from php-xml (required for phpunit) and memcache (required by my framework), all the others have been turned off.
Next to what cweiske suggests, if upgrading PHP is not an option for you and you have problems to locate the source of the segfault, you can use a debugger to find out more.
You can launch gdb this way to debug a PHPUnit session:
gdb --args php /usr/bin/phpunit quiz_service_Test.php
Then type in r to run the program and/or set environment variables first.
set env MALLOC_CHECK_=3
r
You might also consider to install the debugging symbols for PHP on the system to get better results for debugging. gdb checks this on startup for you and leaves a notice how you can do so.
I've had an issue with PHPUnit segfaulting and had trouble finding an answer, so hopefully this helps someone with the same issue later.
PHPUnit was segfaulting, but only:
If there was an error (or more than one)
After all tests had run but before the errors were printed
After a while I realized that it was due to failures on tests that used data providers, and specifically for data providers that passed objects with lots of recursive references. A bell finally went off and I did some digging: the problem is that when you're using data providers and a test fails, PHPUnit tries to create a string representation of the provided arguments for the failure description to tell you what failed, but this is problematic when one of the arguments has some infinite recursion. In fact, what PHPUnit does in PHPUnit_Framework_TestCase::dataToString() (around line 1612) is print out all the arguments provided by the data provider using print_r, which causes the segfault when PHP tries to create a string representation of the infinitely recursive object.
The solution I came to was:
Use a single base class for all my test classes (which fortunately I was already doing)
Override dataToString() in my test base class, to check for these kinds of objects in the data array (which is possible in my case because I know what these objects look like). If the object is present, I return some special value, if not I just pass it along to the parent method.
I had similar problem and by disabling the garbge collactor in
PHPStorm => Edit configuration => Interpreter option : -d
zend.enable_gc=0
Or if you are running your tests from the command line you may try adding :
-d zend.enable_gc=0
When you get a segfault, upgrade your PHP to the latest version. Not only the latest in your package manager, but the latest available on php.net. If it still segfaults, you are sure that the problem has not been fixed yet in PHP itself. Don't bother trying to get rid of a segfault in old version of PHP because it might have been fixed already in a newer one.
Next step is to locating the problem: Make your test smaller and smaller until you can't remove anything (but it still segfaults). If you have that, move the test into a standalone php script that segfaults. Now you have a test script for your bug in the PHP bug tracker.
In addition to https://stackoverflow.com/a/38789046/246790 which helped me a lot:
You can use PHP function gc_disable();
I have placed it in my PHPUnit bootstrap code as well with ini_set('memory_limit', -1);
I had the same problem and could nail it down, that I tried to write a class variable which was not definied:
My class (it's a cakePHP-class) which caused segmentation fault:
class MyClass extends AppModel {
protected $classVariableOne;
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
// This line caused the segmentation fault as the variable doesn't exists
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
I fixed it by adding the second variable:
class MyClass extends AppModel {
protected $classVariableOne;
protected $classVariableTwo; // Added this line
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
Infinite recursion is normally what causes this issue for us. The symptoms of infinite recursion seem to be different when running code under phpunit, than they are when running it in other environments.
If anyone comes across this in relation to PHPunit within Laravel
It took a while to figure out what the issue was. I was going over the differences between my current code and the previous revision and through some trial and error finally got there.
I had two different models that were both including each other with the protected $with override.
This must have been causing some kind of loop that phpunit could not deal with.
Hopefully someone finds this useful.
Please update to the newest XDEBUG. Got the same error while using v3.1.5, and after upgrading to 3.1.6 eveything works.
I got into the same problem. I upgraded the PHPUnit to the 4.1 version (to run the tests) and it was able to show me the object, as pointed by Isaac.
So, if you get to this very same problem, upgrade to PHPUnit >= 4.1 and you'll be able to see the error instead of getting "Segmentation fault" message.
I kept getting a Segmentation fault: 11 when running PHPUnit with Code coverage. After doing a stack trace of the segmentation fault, I found the following was causing the Segmentation fault error:
Program received signal SIGSEGV, Segmentation fault.
0x0000000100b8421a in xdebug_path_info_get_path_for_level () from /usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
I replaced my current xdebug.so in the path above with the latest version from the Komodo Remote Debugging Package the sub-folder of the corresponding downloaded package with the PHP version I have (which is 5.5 for me) and everything worked.
The following fixed a similar issue for me (when the output of the gdb backtrace included libcurl.so and libcrypto.so):
disable /etc/php.d/pgsql.ini:
; Enable pgsql extension module
; extension=pgsql.so
edit /etc/php.d/curl.ini to ensure that pgsql.so is included before curl:
; Enable curl extension module
extension=pgsql.so
extension=curl.so
curl.cainfo=/home/statcounter/include/config/cacert.pem
if you have an object with property pointing to the same object, or other sort of pointer loops, you will have this message while running
serialize($object);
And if you are a Laravel user, and you are dealing with models. And if you think, you will never have this problem, because you avoiding pointer loops by using $hidden property on your models, please be advised, the $hidden property does not affect serialize, it only affects casting to JSON and array.
I had this problem, when I had a model saved into a property of a Mailable object.
fixed with
$this->model->refresh();
in a __construct method , just before the whole object is serialized.
This related to code not extension. In my case i had these two files
Test Case
Example Test
In Test Case there is method called createApplication. Just leave it empty.
In Example Test you can create the method and fill with
$this->assertTrue(true)
Above is basic setup hope you can extend the requirement as you need.