recently upgraded a 5.3 project to 5.4 and all seemed good.
Today I started to implement Dusk however had hit an issue when running the example test
☁ footy-finance [5.4] ⚡ php artisan dusk
PHPUnit 6.0.0 by Sebastian Bergmann and contributors.
E 1 / 1 (100%)
Time: 162 ms, Memory: 6.00MB
There was 1 error:
1) Tests\Browser\ExampleTest::testBasicExample
ReflectionException: Class config does not exist
/Users/owen/Sites/footy-finance/vendor/laravel/framework/src/Illuminate/Container/Container.php:681
/Users/owen/Sites/footy-finance/vendor/laravel/framework/src/Illuminate/Container/Container.php:565
/Users/owen/Sites/footy-finance/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php:105
/Users/owen/Sites/footy-finance/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php:263
/Users/owen/Sites/footy-finance/vendor/laravel/dusk/src/TestCase.php:203
/Users/owen/Sites/footy-finance/vendor/laravel/dusk/src/TestCase.php:40
I've had a look at line 40 of TestCase.php and its
public function baseUrl()
{
return config('app.url');
}
So it does look like something to do with the global config helper anybody have any ideas?
I'm running
PHP 7.0.14
Laravel/Framework 5.4.8
Laravel/Dusk 1.0.5
The full composer.lock can be seen https://gist.github.com/OwenMelbz/c05172b33f6eb4483e37a56469b53722
Fingers crossed you guys have some ideas!
Cheers :)
I had this error in the log
Class config does not exist
the problem with me was that in the .env file I had set a configuration variable in the following way:
APP_NAME=Application Name
note the space. When I changed it to this:
APP_NAME="Application Name"
the problem got fixed
The issue is with .env file
App_Name
in the original file its written this way>>> APP_NAME=Application Name
Make it like this APP_NAME="Application Name"
In my case, this solution works:
1) Remove all contents of the bootstrap/cache folder
2) Run the composer dump command
For anybody else who has had this issue.
I had prefer stable set in the composer file, which installed PHPUnit 6.
This was "made stable today" - thus it installed during a composer update.
Downgrading to PHPUnit 5 fixes the issue - so was bad timing starting it today.
I just ran into the the same issue, in my case the .env was all clean, no unwrapped empty spaces.
This error message can also occur when writting/debugging a test case, using the setup() method in that test, forgetting to call parent::setup() as the first statement in that function.
protected $stuf;
function setup() {
parent::setup();
$this->stuf = 'stuf';
}
I found very useful info here on what else could happen when you're getting this error message.
I've also had this issue. For me it was caused by calling the config() function inside a dataProvider method. DataProviders are called before the createApplication() method initialises the application, and populates the DI container. Hence config() fails because the app('config') call in the helper function can't resolve the config class from the container.
I'm very late for the party here but for anyone experiencing the same issue with Laravel's unit test and none of the above solutions work, you can look into mine and see if this might help.
In my case, I was trying to call a method that will remove all the test keys that persisted in my Redis database when I run the unit test. The method is called in the tearDown method of the class. The error occurs because the parent constructor is called before the actual tearDown code is executed. That's the reason why I'm having the error.
Instead of this one......
/**
* tearDown is executed after test stub
*/
protected function tearDown()
{
parent::tearDown();
$this->deleteTestKeys();
}
Change it to this one...
protected function tearDown()
{
$this->deleteTestKeys();
parent::tearDown();
}
In this case, the class' is not totally destroyed yet and the Laravel's config method will get called accordingly.
I had this in a Lumen application today. After some investigation and playing around, I found that it was because in PHPStorm it was adding the --no-configuration option onto the phpunit command because I hadn't configured my PHPUnit setup for the project in the IDE.
I corrected that by clicking 'Run > Edit Configurations' and then under 'Defaults > PHPUnit' click the little button to the far right of the 'Use alternative configuration file:' option and set the 'Default configuration file:' to the full path to your project's phpunit.xml.
Hope this helps!
I saw this error after following some dodgy installation instructions for a third party module, which said to register a service provider in bootstrap/app.php
$app->singleton(...);
$app->singleton(...);
$app->register(\Third\Party\ServiceProvider::class);
This caused $this->app['config'] to generate the error BindingResolutionException: Target class [config] does not exist.
I fixed it by putting it in config/app.php, where it belongs:
/*
* Package Service Providers...
*/
Third\Party\ServiceProvider::class,
Related
I'm trying to get a TYPO3 v8 system updated to TYPO3 v9, but when it comes to unit-testing, I got some errors. I was able to fix some of them on my own but this one here's a very difficult one for me, because unit-testing is somewhat new to me in general.
I already searched the web, the TYPO3 documentation (which seems like the important parts are missing?), asked some friends and tried some things on my own, but nothing helped.
$this->environmentMock = $this->createMock(Environment::class);
$this->environmentMock->expects($this->once())
->method("::isCli")
->will($this->returnValue(TRUE));
I'm expecting to manually override the static function ::isCli() that comes with the Environment class. If that's not possible, is there any other "workaround", like setting a protected variable or something like that?
Currently this is my error message:
Trying to configure method "::isCli" which cannot be configured because it does not exist, has not been specified, is final, or is static
Thanks in advance!
Update 1:
After using #susis tip, I get the following error when appending the code:
TypeError: Return value of TYPO3\CMS\Core\Core\Environment::getContext() must be an instance of TYPO3\CMS\Core\Core\ApplicationContext, null returned
Additional information: My project is just an extension folder with TYPO3 v9 sources required in its own composer.json. No web, no htdocs, just the extension folder.
Update 2:
Here's a full gist of my test file.
Update 3:
Even the debugger isn't helping me in this case, see attached screenshot:
xdebug phpstorm applicationcontext environment screenshot
Update 4:
I updated the gist, added the environment vars to the phpunit.xml file and added parent::setUp() to the top of the setUp() method but the error is still the same:
TypeError : Return value of TYPO3\CMS\Core\Core\Environment::getContext() must be an instance of TYPO3\CMS\Core\Core\ApplicationContext, null returned
/Users/xyz/my_redirect/public/typo3/sysext/core/Classes/Core/Environment.php:97
/Users/xyz/my_redirect/Tests/Unit/Hooks/RequestHandlerHookTest.php:41
Update 5:
I updated the gist and removed the environment settings from the phpunit.xml due to what I've seen that they didn't work either. At this moment, the test is working but I'm still not sure if it's done the right way. Thanks for your help!
You can initialize the Environment you want in your tests, for example with:
Environment::initialize(
Environment::getContext(),
true,
false,
Environment::getProjectPath(),
Environment::getPublicPath(),
Environment::getVarPath(),
Environment::getConfigPath(),
Environment::getBackendPath() . '/index.php',
Environment::isWindows() ? 'WINDOWS' : 'UNIX'
);
This is the same way as it is done in TYPO3 Core tests and allows you to customize the complete environment. If you are using the TYPO3 testing framework / UnitTestCase base classes, you can use the property protected $backupEnvironment = true; to make sure the environment is reset after your test.
For an example, you can have a look at the ResourceCompressorIntegrationTest
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
Setup 1: Echoing back from the route works in PHPUnit
routes.php
Route::get('signup', function(){
return "Hello World!";
});
/tests/SignupTest.php
class SignupTest extends TestCase {
public function testIndex(){
$this->call('GET', 'signup');
$this->assertResponseOK();
}
}
Running PHPUnit returns the following:
OK (1 test, 1 assertion)
Setup 2: But PHPUnit can't find the Signup Controller when I route to it
routes.php
Route::get('signup', array('uses' => 'Signup#process'));
/app/controllers/Signup.php
class Signup extends BaseController {
public function process(){
echo "Hello World!";
}
}
/tests/SignupTest.php
class SignupTest extends TestCase {
public function testIndex(){
$this->call('GET', 'signup');
$this->assertResponseOK();
}
}
PHPUnit returns the following:
There was 1 error:
1) SignupTest::testIndex
ReflectionException: Class Signup does not exist
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php:476
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php:416
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:423
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php:77
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php:50
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Routing/Router.php:900
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Routing/Route.php:118
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Routing/Router.php:964
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Routing/Router.php:934
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:677
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:652
/Applications/MAMP/htdocs/laravel/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/Client.php:82
/Applications/MAMP/htdocs/laravel/vendor/symfony/browser-kit/Symfony/Component/BrowserKit/Client.php:319
/Applications/MAMP/htdocs/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Testing/TestCase.php:74
/Applications/MAMP/htdocs/laravel/app/tests/SignupTest.php:12
FAILURES!
Tests: 1, Assertions: 0, Errors: 1.
Setup information:
Laravel 4.1
PHPUnit 3.7.28
Both installed by Composer
MAMP running PHP 5.4.4 on Mac OS X 10.8
I don't think I've changed anything in the core/config files of Laravel or PHPUnit.
Things I've tried:
I found a few answers about this type of issue (both on SO and other sites), where the answers suggested fixing mistakes in names of class/file/method, e.g.:
Laravel Controller not working
I don't think this is an issue here, because I've checked all the names. Also it returns "Hello World!" as expected for both the above routes when tested in a browser, suggesting that the route is working fine in Laravel. Problem seems to be with PHPUnit.
My Question: Why can't PHPUnit find the Signup Class in app/controllers?
I'd assumed that because there was a phpunit.xml file in the basic Laravel install, that PHPUnit would know about it. That assumption turned out to be incorrect.
The Problem
PHPUnit wasn't loading phpunit.xml, which meant the bootstrap file in bootstrap/autoload.php wasn't being loaded, so PHPUnit had no idea where any of the class files were, including Signup.php.
The Solution
I added the file path to phpunit.xml in the --configuration switch when I ran PHPUnit:
--configuration /Applications/MAMP/htdocs/laravel/phpunit.xml
General Advice
If PHPUnit tells you it can't find a class, check that it's loading phpunit.xml and/or your bootstrap file. Make sure your phpunit.xml file points correctly to your bootstrap file and that your bootstrap file is configured correctly to load the required classes.
Also, as pointed out in my question, problems can also be caused by inconsistencies between class/file/method names.
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.
I just installed PHPUnit 3.5 on my system, upgrading it from 3.4, and I'm having some trouble with the new version. When I try to run a test, I always get the same output. Here's what I get when I try to run on the command line the StackTest example from the PHPUnit manual, example 4.1:
> phpunit StackTest
X-Powered-By: PHP/5.2.17
Content-type: text/html
PHPUnit 3.5.13 by Sebastian Bergmann.
Class StackTest could not be found in StackTest.php.
Worse yet, when I try to run it from a web browser, I get the following output:
Fatal error: Class 'PHPUnit_Framework_TestCase' not found in /path/to/tests/StackTest.php on line 2
Does anyone know how to set this up? Thanks.
I had the problem you described on Windows.
The problem was in the file pear\PHPUnit\Runner\StandardTestSuiteLoader.php on line 131 an it was caused by different drive letter case in file name in the condition
if ($class->getFileName() == realpath($suiteClassFile)) {
My simple fix is to change this line to be case insensitive
if (strtolower($class->getFileName()) == strtolower(realpath($suiteClassFile))) {
phpunit MyTestClass
In my case
MyTestClass.php should be in the project home directory
it should starts with long php open tag (<?php, not <?)
it should contain class MyTestClass extends PHPUnit_Framework_TestCase {
I know this is most likely not the best way, just point for a beginner to start with.
Try
pear upgrade pear
(if it asks you to channel upgrade do so)
and then
pear install --force --alldeps phpunit/phpunit
and try again.
The 3.5 upgrade combined with a buggy pear installer (1.9.1 has a kinda annoying bug so make sure you are really on 1.9.2) can be a pain sometimes.
I think your PHPUnit Class named StackTest, and the class you want to test is also named StackTest. This will cause a path conflict in PHPUnit.
Make these 2 names different and you will get this resolved.
In my case, this problem was caused by including PHPUnit in the source file via require_once:
require_once 'phar://phpunit.phar';
Removing that line made my test case runnable.
This error can also be caused when you forget to have your test class extend the PHPUnit TestCase class, like
class MyTestClass extends \PHPUnit\Framework\TestCase { ...
I was able to fix the problem. It was a result of how I was loading the class. I used my arguments in the argument array like so and it worked. But there were a lot of other problems with the classpath etc that I had to fix first. To see a working solution look here (http://www.siteconsortium.com/h/p1.php?id=php002).
$command = new PHPUnit_TextUI_Command();
$command->run(array('test', 'testCase', 'c:\workspace\project\testCase.php'), true);
Starting from PHPUnit 9, it is required that the filename match the class name in the test.
#4105: Deprecate multiple test case classes in single file and test case class name differing from filename
So test-plugin.php with a class name PluginTest will fail with this error. To fix it, you'd need to rename the file to PluginTest.php.
Bad error message IMO.
It sounds like PHPUnit isn't on your include path. To easily test this, try this:
$ phpunit --include-path /path/to/PHPUnit StackTest