I am using Netbeans 8.2 and PHPUnit 4.8.36 along with PHP 5.6.36 and I have some issue when there is some Fatal Error Exception within the tests functions.
/**
* #runInSeparateProcess
*/
public function testEquals() {
thisMethodDoesNotExistsAndTestShouldFail();
}
It works fine if I add the annotation #runInSeparateProcess so that means test fails.
But if I have it just like this:
public function testEquals() {
thisMethodDoesNotExistsAndTestShouldFail();
}
The test passes which in my opinion is wrong.
The idea is that I don't want to add the annotations for each test and there are hundred of tests already so I can't just go and add to every of them.
Is there any way that I can configure PHPUnit to run the tests in separate process.
For ex my colleague of mine doesnt need to add this annotation and it works for her as expected.
Any idea where I should look this to solve or anyone had this issue before? Do u think the php version would matter here, since my colleague is using php 5.3.x and it works for her. Also I am using Zend Framework v1
I've just started using Travis CI to test my PHP code. Sometimes, builds fail with the message
PHP Fatal error: Class 'PHPUnit_Framework_TestCase' not found in /home/travis/build/ms609/citation-bot/tests/phpunit/expandFnsTest.php on line 13
On other occasions, without my having changed any relevant code, the builds succeed.
This makes me suspect that the issue is at Travis's end rather than my own.
This makes me wonder: is there anything that I can do to reduce the likelihood of my encountering this error? And on builds when the error arises, is it possible to have Travis re-attempt the build without making a new commit?
I had inherited a testcase written using an older version of phpunit. For backwards compatibility, following advice elsewhere, I had added the code
if (!class_exists('\PHPUnit\Framework\TestCase') &&
class_exists('\PHPUnit_Framework_TestCase')) {
class_alias('\PHPUnit_Framework_TestCase', 'PHPUnit\Framework\TestCase');
}
What I needed to do next was replace
class myTest extends PHPUnit_Framework_TestCase {
with
class myTest extends PHPUnit\Framework\TestCase {
With regards to the second part of the question, signing in to Travis CI reveals a "restart build" option on the build page.
I want to do performant testing, so I thought about using PHPUnit_Framework_TestCase instead of TestCase in my test files. I'm sacrificing http requests testing, but I want at least to use some of the components of Laravel (like its providers and such).
Here's what it looks like :
<?php
class ChatTest extends PHPUnit_Framework_TestCase
{
/** #test */
public function chat_can_be_accepted()
{
$this->chat->setStatus(Chat::CHAT_STATUS_WAIT_MASTER);
$this->chat->accept();
$this->assertEquals(Chat::CHAT_STATUS_WAIT_CONFIRM, $this->chat->getStatus());
}
}
I have an error saying Call to a member function connection() on null. setStatus actually uses Laravel internals in this example (something as simple as a relationship that needs the app).
I already tried switching every providers, but it seems code is not even going through providers. Also tried changing PHP versions, or extensions.
I'm answering my own question for future reminders, and also because I never found this answer anywhere else.
At this point I was using PHPStorm and it doesn't auto load the phpunit.xml file when launching tests by default.
That line in the file launches Laravel (works with Lumen too) along with the tests : bootstrap="bootstrap/app.php".
This is needed to use Laravel internals even without using their test frameworks.
To use this in PHPStorm :
To use this in CLI :
phpunit --configuration phpunit.xml
In PHPUnit 3.6.4, when I run a test based on PHPUnit_Extensions_SeleniumTestCase, and I use
$this->markTestSkipped();
or
$this->markTestIncomplete();
I have the test skipped (S) or marked as incomplete (I).
But after updating PHPUnit to 3.6.10 - the latest now - these functions seem to fail the test by producing an error instead of skipping it.
More examples, take this test:
class ExampleTest extends PHPUnit_Extensions_SeleniumTestCase
{
public function testMyCase()
{
$this->markTestIncomplete();
}
}
It will still run the test and give you this output, if you don't have Selenium server running:
PHPUnit 3.6.10 by Sebastian Bergmann.
E
Time: 0 seconds, Memory: 6.25Mb
There was 1 error:
1) ExampleTest::testMyCase
RuntimeException:
/usr/bin/phpunit:46
FAILURES!
Tests: 1, Assertions: 0, Errors: 1
If you do have Selenium server running you result will be slightly different but you will still have an error. This is for Selenium tests only, tests extending PHPUnit_Framework_TestCase seems to be ok. To confirm that, change the class you are extending it from to PHPUnit_Framework_TestCase:
class ExampleTest extends PHPUnit_Framework_TestCase
{
public function testMyCase()
{
$this->markTestIncomplete();
}
}
And you will have this result:
PHPUnit 3.6.10 by Sebastian Bergmann.
I
Time: 0 seconds, Memory: 5.25Mb
OK, but incomplete or skipped tests!
Tests: 1, Assertions: 0, Incomplete: 1.
So my question is: is this a bug in PHPUnit 3.6.10? Is this some cool feature I don't know and I am doing something wrong?
I ran into the same problem and it looks like that this issue is not tied to PHPUnit's core but rather to the PHPUnit Selenium extension. A ticket has already been filed in their issue tracking system.
I tracked down the exact line where the error is thrown and found it in Extensions/SeleniumTestcase.php on line 1215:
1213: // gain the screenshot path, lose the stack trace
1214: if ($this->captureScreenshotOnFailure) {
1215: throw new PHPUnit_Framework_Error($buffer, $e->getCode(), $e->getFile(), $e->getLine(), $e->getTrace());
1216: }
As you can see, this error occurs only if $this->captureScreenshotOnFailure is set to true. So the workaround I am currently using is to set $this->captureScreenshotOnFailure=true in the setUp() method of my Selenium tests and in each test that is marked as skipped I disable the screenshots manually before calling the skip method:
public function setUp() {
[...]
$this->captureScreenshotOnFailure = true;
}
/**
* #test
*/
public function mySkippedTest() {
$this->captureScreenshotOnFailure = false;
$this->markTestSkipped();
[...]
}
This works for me as it correctly marks skipped Selenium tests as such but still retains the screenshot feature for all the other tests.
However, if you have a huge number of skipped tests in your projects this might be a bit tedious to do and I can't guarantee that there aren't any other side effects, as I'm not all too familiar with PHPUnit's internals. In this case probably the best solution would be to wait with the update until it is fixed by the creators of phpunit-selenium as it seems that they are already aware of this issue.
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.