[5.1] [5.2] Error handler hides PHPUnit errors

Question

[5.1] [5.2] Error handler hides PHPUnit errors

sebastianbergmann opened this issue 9 years ago · 95 comments

I discovered a bug in PHPUnit (sebastianbergmann/phpunit#1935) while working on a Laravel 5.1 project:

$ composer create-project laravel/laravel --prefer-dist

$ cd laravel

$ ./vendor/bin/phpunit --coverage-html /does-not-exist
PHPUnit 4.8.16 by Sebastian Bergmann and contributors.

.

Time: 429 ms, Memory: 18.75Mb

OK (1 test, 2 assertions)

Generating code coverage report in HTML format ...PHP Fatal error:  Uncaught exception 'Illuminate\Contracts\Container\BindingResolutionException' with message 'Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable.' in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php:745
Stack trace:
#0 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php(627): Illuminate\Container\Container->build('Illuminate\\Cont...', Array)
#1 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#2 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(154): Illuminate\Foundation\Application->make('Illuminate\\Cont...')
#3 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(79): Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler()
#4 [internal function]: Illuminate\Foundation\Bootstrap\Handle in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 745
PHP Fatal error:  Uncaught exception 'Illuminate\Contracts\Container\BindingResolutionException' with message 'Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable.' in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php:745
Stack trace:
#0 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php(627): Illuminate\Container\Container->build('Illuminate\\Cont...', Array)
#1 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#2 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(154): Illuminate\Foundation\Application->make('Illuminate\\Cont...')
#3 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(79): Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler()
#4 /home/sb/test/laravel/vendor/laravel/framework/src/Illumina in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 745

The reason why I am opening this ticket is because nowhere in the stacktrace do I see PHPUnit and/or PHP_CodeCoverage. The fact that PHPUnit was not handling an exception raised by PHP_CodeCoverage was not apparent at all from looking at the error I got. Maybe the error handler is too eager?

Answer 1 · 2015-11-06T14:18:43.000Z

Ping @taylorotwell.

Answer 2 · 2015-11-06T15:33:37.000Z

Yeah I've been meaning to look into this :) ... thanks for the reminder!

Answer 3 · 2015-11-06T16:53:05.000Z

Ok, closing #10829.

Answer 4 · 2015-11-24T20:02:09.000Z

Hello, tried with PHPUnit 5.0.9 but I get the same error. Maybe something's unbinding the Handler implementation between cases?

Answer 5 · 2015-12-24T00:29:19.000Z

Got the same issue
PHPUnit 5.1.3
Latest laravel version [5.2]

Answer 6 · 2015-12-24T10:44:47.000Z

We ONLY support phpunit 4.8.

Answer 7 · 2015-12-24T10:45:33.000Z

Upgrading to 5.x means you have to drop php 5.5 support from your app. We've done that in L5.3.

Answer 8 · 2015-12-24T12:17:12.000Z

Reverted to phpunit 4.8 same exception

Answer 9 · 2015-12-24T12:26:09.000Z

Is this only with code coverage turned on?

Answer 10 · 2015-12-24T12:26:30.000Z

If so, you need to make sure phpunit doesn't load your routes file, or any other php files "with consequences".

Answer 11 · 2016-02-15T20:11:16.000Z

I can confirm that this also occurs on my build..

Here's the log that indicates the error:

PHP Fatal error:  Uncaught exception 'Illuminate\Contracts\Container\BindingResolutionException' with message 'Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable.'

Strangely, it only occurs when I tried to use PHP 5.6. Does not occur on HHVM or 7.0.

Tested on Travis-CI

Answer 12 · 2016-02-27T18:09:52.000Z

I understand we don't want PhpUnit 5.x in Laravel 5 yet, all the related reasons. My question is: do we even know what is the cause and a possible solution? @taylorotwell

Answer 13 · 2016-03-11T09:02:05.000Z

with behat we have the same problem.
Current Laravel version is v5.2.22

Answer 14 · 2016-03-16T09:01:43.000Z

Issue confirmed on my application with

PHPUnit 4.8.24
Laravel 5.1.31

Update: I had customised a bit the exception handler to have Whoops rendering but after reverting it to the original https://raw.githubusercontent.com/laravel/laravel/v5.1.4/app/Exceptions/Handler.php
the issue is gone

Answer 15 · 2016-03-16T09:04:58.000Z

No need for confirmations please. We know it's broken. ;)

Answer 16 · 2016-03-16T09:10:20.000Z

@GrahamCampbell any ETA or anything I can do to speed the thing up?

Answer 17 · 2016-03-16T10:49:14.000Z

Well, if you could fix it, that would be great. The problem is somewhat non-trivial though, so good luck if you want to give it a go. ;)

Answer 18 · 2016-03-29T06:18:54.000Z

is there any fix / solution for this ?

Answer 19 · 2016-03-30T17:41:23.000Z

I am running into this issue as well. Any ideas on a fix for this yet @taylorotwell?

For me, it is only happening when I run only a part of my tests with code coverage. PHP 5.6 and PHPUnit 4.8.24

Answer 20 · 2016-03-30T18:13:01.000Z

I think I know what's going on here then, if it's only happening with code coverage.

Answer 21 · 2016-03-30T18:13:26.000Z

Make sure you exclude any plain php files such as your routes.php file.

Answer 22 · 2016-03-30T18:13:45.000Z

Excludes work like this: https://github.com/laravel/framework/blob/5.2/phpunit.xml#L24.

Answer 23 · 2016-03-30T18:17:32.000Z

@GrahamCampbell Code coverage is working if I run the whole suite... phpunit if I run phpunit tests/Http/Controllers/ --coverage-html code-coverage or target a test using the filter flag, that is when it errors... I am on livecoding right now and would be happy to show you ... livecoding.tv/lamarus

Answer 24 · 2016-03-30T18:18:54.000Z

Can you try excluding that file please.

Answer 25 · 2016-03-30T18:20:21.000Z

I'm watching your stream. I'm pretty sure if you run all of phpunit with coverage on, then it'll break in the same way.

Answer 26 · 2016-03-30T18:53:30.000Z

Thanks everyone. Debugging this with @bretterer, we can see that phpunit is requiring the routes file, which has consequences.

Answer 27 · 2016-03-30T18:53:33.000Z

See laravel/laravel#3725.

Answer 28 · 2016-03-31T08:41:40.000Z

@GrahamCampbell , that must be the reason: my tests run without error, without your fix of laravel/laravel#3725 and I don't have routes file in my App (it's all inside RouteServiceProvider class). Guess that was the reason. Thanks!

Answer 29 · 2016-05-09T06:53:31.000Z

still having this error
PHP 7
PHPUnit 4.8.24

Answer 30 · 2016-05-11T15:56:24.000Z

Yeah I'm picking this up occassionally too.

PHPUnit 4.8.24, PHP 7.0.5-2+deb.sury.org~trusty+1 (cli).

Will dig deeper!

Answer 31 · 2016-05-11T16:53:07.000Z

Well don't I feel silly - after digging through the handleException() on HandleExceptions it has become clear that I had a syntax error in one of my middleware.

Not particularly helpful that this is covered up by the PHPUnit and Laravel combo though!

Answer 32 · 2016-05-11T18:38:05.000Z

mine wasn't a syntax error, i install phpunit v5.* globally on my linux machine, so when i run phpunit it uses the default instead of the one with the project so, fixed my by running phpunit like this;
vendor/bin/phpunit

Answer 33 · 2016-05-11T18:52:57.000Z

Fair enough. I dont think it is particularly helpful that a syntax error
isnt output when caught by Phpunit. Admittedly a linter would avoid such an
occurance, and better code coverage would help too!
On 11 May 2016 19:38, "Canaan Etaigbenu" notifications@github.com wrote:

mine wasn't a syntax error, i install phpunit v5.* globally on my linux
machine, so when i run phpunit it uses the default instead of the one with
the project so, fixed my by running phpunit like this;
vendor/bin/phpunit

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#10808 (comment)

Answer 34 · 2016-07-06T16:19:22.000Z

I'm getting the same error here, using PHP Unit 4.8.26 and PHP 7.0.4-7ubuntu2.1 (cli)

If I run phpunit directly i get the error.

~/laravel$ phpunit

But if I run from vendor/bin folder it works fine.

Answer 35 · 2016-07-06T16:56:17.000Z

I had the same issue. (Using Laravel 5.2)
The problem was that i had a newer version of phpunit installed globally (5.4.4).
So by running phpunit command the global one was used.

Solutions:

Use ./vendor/bin/phpunit instead;
Downgrade the global phpunit, after which you can use the phpunit command regularly.

composer global remove phpunit/phpunit
composer global require 'phpunit/phpunit=~4.0'

Or just don't globally require PHPUnit.

Hope somebody finds this useful.

Answer 36 · 2016-07-11T16:43:06.000Z

@mihailomisic Hi - I'm trying your second solution but I'm getting "Could not find package =~4.0 at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability" when I try to install the phpunit globally. Any suggestions? Thanks.

Answer 37 · 2016-07-11T17:00:10.000Z

Hmm strange I just did it again, just to check, and everything seems to be working correctly.
Try again by literally copy-pasting my snippet, and if that fails try installing it "manually".
Here's a link to the instructions: Installing PHPUnit
And the download link. (instruction link downloads 5.4.6)

Good luck!

Answer 38 · 2016-08-17T16:14:27.000Z

I'm seeing this issue on a nearly fresh install of L5.2.

composer.json:

{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "php": ">=5.5.9",
        "laravel/framework": "5.2.*",
        "guzzlehttp/guzzle": "^6.2",
        "watson/validating": "^2.2"
    },
    "require-dev": {
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "0.9.*",
        "phpunit/phpunit": "~4.0",
        "symfony/css-selector": "2.8.*|3.0.*",
        "symfony/dom-crawler": "2.8.*|3.0.*"
    },
    "autoload": {
        "classmap": [
            "database"
        ],
        "psr-4": {
            "App\\": "app/"
        }
    },
    "autoload-dev": {
        "classmap": [
            "tests/TestCase.php"
        ]
    },
    "scripts": {
        "post-root-package-install": [
            "php -r \"copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "php artisan key:generate"
        ],
        "post-install-cmd": [
            "Illuminate\\Foundation\\ComposerScripts::postInstall",
            "php artisan optimize"
        ],
        "post-update-cmd": [
            "Illuminate\\Foundation\\ComposerScripts::postUpdate",
            "php artisan optimize"
        ]
    },
    "config": {
        "preferred-install": "dist"
    }
}

Installed phpunit is within the appropriate range.

./vendor/bin/phpunit --version
PHPUnit 4.8.27 by Sebastian Bergmann and contributors.

And it's not installed globally.

composer global remove phpunit/phpunit
phpunit/phpunit is not required in your composer.json and has not been removed
Package "phpunit/phpunit" listed for update is not installed. Ignoring.

Php version

php -v
PHP 5.5.38 (cli) (built: Jul 25 2016 13:50:13)

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false" backupStaticAttributes="false" bootstrap="bootstrap/autoload.php" colors="true" convertErrorsToExceptions="true" convertNoticesToExceptions="true" convertWarningsToExceptions="true" processIsolation="false" stopOnFailure="false">
  <testsuites>
    <testsuite name="Application Test Suite">
      <directory suffix="Test.php">./tests</directory>
    </testsuite>
  </testsuites>
  <filter>
    <whitelist processUncoveredFilesFromWhitelist="true">
      <directory suffix=".php">./app</directory>
      <exclude>
        <file>./app/Http/routes.php</file>
      </exclude>
    </whitelist>
  </filter>
  <logging>
      <log type="coverage-html" target="./tests/output/coverage/" charset="UTF-8" yui="true" highlight="true" lowUpperBound="50" highLowerBound="80"/>
      <log type="testdox" target="./tests/output/testdox.html"/>
  </logging>
  <php>
    <env name="APP_ENV" value="testing"/>
    <env name="CACHE_DRIVER" value="array"/>
    <env name="SESSION_DRIVER" value="array"/>
    <env name="QUEUE_DRIVER" value="sync"/>
    <env name="DB_CONNECTION" value="sqlite"/>
    <env name="DB_DATABASE" value=":memory:"/>
  </php>
</phpunit>

Error message is the same as the OP. Any suggestions would be helpful.

Answer 39 · 2016-08-23T00:16:40.000Z

This is still a bug. Think it might help people out to at least reopen it so they know it's still an unresolved problem. That exclude filter doesn't fix.

Answer 40 · 2016-08-23T19:39:40.000Z

Confirmed, still an issue.

Answer 41 · 2016-08-24T13:18:07.000Z

Yes, still an issue. So confirmed.

Question: Does codecoverage spawns an additional phpunit instance? Because there was a phpunit in my global environment but I did ran the one from vendor/bin and still got the error.

Removed the global one and now it's ok.

phpunit version 4.8.27
Laravel 5.3.1

Answer 42 · 2016-08-24T17:28:36.000Z

Hi,
I have tried

composer global remove phpunit/phpunit
sudo apt-get purge phpunit

and
./vendor/bin/phpunit
works

Laravel Framework version 5.2.44
PHP 7.0.8-0ubuntu0.16.04.2
PHPUnit 4.8.27

Answer 43 · 2016-09-06T14:29:10.000Z

I am experiencing this same problem.

Laravel version: 5.3
PHP version: 7.0.10
PHPUnit version: 5.5.2

The following command throws this exception when generating the coverage report:

phpdbg -S cli -qrr vendor/bin/phpunit --coverage-html coverage

None of the following commands throw the exception:

phpdbg -qrr vendor/bin/phpunit --coverage-html coverage
vendor/bin/phpunit --coverage-html coverage
phpdbg -S cli -qrr vendor/bin/phpunit
phpdbg -S cli -qrr vendor/bin/phpunit --coverage-text

My reasoning for the original command is because there is currently a bug in phpunit that doesn't calculate coverage correctly, so I use phpdbg; overriding the SAPI name to "cli" is required so that migrations run in tests; and of course I want an html coverage report.

I am using the relative path to phpunit, and I added the two routes files to my exclude list, but I still have the issue. I will try to bang on this and see if I get anywhere.

It's worth noting that, in my case, I'm getting what looks like two different exceptions, which means that this may be a slightly different issue (and probably one with my code) than the issue recorded here. My full output:

[PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/user/api/vendor/laravel/framework/src/Illuminate/Container/Container.php:748
Stack trace:
#0 /home/user/api/vendor/laravel/framework/src/Illuminate/Container/Container.php(629): Illuminate\Container\Container->build('Illuminate\\Cont...', Array)
#1 /home/user/api/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(699): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#2 /home/user/api/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(154): Illuminate\Foundation\Application->make('Illuminate\\Cont...')
#3 /home/user/api/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(79): Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler()
#4 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleException(Object(ErrorE in /home/user/api/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 748]
[PHP Fatal error:  Uncaught ErrorException: include(/home/user/api/vendor/symfony/debug/Exception/FatalErrorException.php): failed to open stream: Too many open files in /home/user/api/vendor/composer/ClassLoader.php:412
Stack trace:
#0 /home/user/api/vendor/composer/ClassLoader.php(412): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'include(/home/j...', '/home/user/...', 412, Array)
#1 /home/user/api/vendor/composer/ClassLoader.php(412): include()
#2 /home/user/api/vendor/composer/ClassLoader.php(301): Composer\Autoload\includeFile('/home/user/...')
#3 [internal function]: Composer\Autoload\ClassLoader->loadClass('Symfony\\Compone...')
#4 /home/user/api/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(131): spl_autoload_call('Symfony\\Compone...')
#5 /home/user/api/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(118): Illuminate\Foundation\Bootstrap\HandleExceptions->fatalExceptionFromError(Array, 0)
#6 [i in /home/user/api/vendor/composer/ClassLoader.php on line 412]

Note the failed to open stream: Too many open files

Edit: I've verified that this problem is only happening when I try to run my full test suite. If I start commenting out some tests, it runs successfully. The test suite that makes it fail tests code that uses a RecursiveDirectoryIterator, and based on this SO question, this may be the cause of my problem.

Final edit: I solved my problem by permanently increasing my soft and hard ulimit from 1024 to something much higher, like 50000. It doesn't seem like an ideal solution and unfortunately does nothing to help the larger problem reported in this issue. I'll leave this here though in case anyone encounters the same problem.

Answer 44 · 2016-09-07T02:09:18.000Z

A globally-installed PHPUnit used to work fine on my previous Jenkins CI flow.. now I'm getting the same results as others (after migrating to a different box):

Only using PHPUnit installed local to the framework will work. Not sure what differed from my old setup.

The workaround is fine with me, however.. when invoking ant I just have my build.xml use vendor/phpunit/phpunit/phpunit

Answer 45 · 2016-09-07T08:13:00.000Z

If it's any value-add to this conversation, if I'm running as root sudo su then I get this error. If I'm running under, say for instance vagrant, then no error.

Answer 46 · 2016-10-12T16:43:12.000Z

Mine was different phpunit in the system and the application. Removed one from system and updated composer.json to "phpunit/phpunit": "5.*",

Now it runs fine. :)

Answer 47 · 2016-10-19T10:24:25.000Z

@masterjus have you solved it with behat?

Answer 48 · 2016-11-03T12:04:20.000Z

@codru @masterjus I'm experiencing this problem with behat as well
PHP 7.0.8-2+deb.sury.org~xenial+1
behat version 3.2.1

Are there any plans to fix this? or any workaround?

Answer 49 · 2016-12-16T15:43:24.000Z

+1 Same issues with 5.1

Answer 50 · 2016-12-23T19:51:29.000Z

The issue for me was that I had a custom listener that was implementing PHPUnit_Framework_TestListener that was throwing an exception that wasn't being handled. I fix the issue by adjusting the listener to handle the exception and everything started working.

Answer 51 · 2017-03-09T10:54:16.000Z

I've encountered this issue on circle-ci

php 7.0.4
phpunit 5.7.5

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php:804
Stack trace:
#0 /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php(687): Illuminate\Container\Container->notInstantiable('Illuminate\\Cont...')
#1 /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php(565): Illuminate\Container\Container->build('Illuminate\\Cont...')
#2 /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(702): Illuminate\Container\Container->make('Illuminate\\Cont...')
#3 /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(155): Illuminate\Foundation\Application->make('Illuminate\\Cont...')
#4 /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(80): Illuminate\Foundation\Boot in /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 804

Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 804

Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 804

Call Stack:
  121.6158   17070864   1. Illuminate\Foundation\Bootstrap\HandleExceptions->handleException() /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php:0
  121.6158   17070864   2. Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler() /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php:80
  121.6159   17070864   3. Illuminate\Foundation\Application->make() /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php:155
  121.6159   17070864   4. Illuminate\Container\Container->make() /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:702
  121.6159   17070864   5. Illuminate\Container\Container->build() /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php:565
  121.6161   17073296   6. Illuminate\Container\Container->notInstantiable() /home/ubuntu/basal/vendor/laravel/framework/src/Illuminate/Container/Container.php:687

Answer 52 · 2017-03-09T19:46:08.000Z

Just ran into this issue only when running a coverage report.

laravel 5.1.45
phpunit 4.8.35

Here's how I fixed it.

phpunit.xml

<filter>
    <whitelist processUncoveredFilesFromWhitelist="true">
        <directory suffix=".php">./app/</directory>
        <exclude>
            <file>app/Http/routes.php</file>
        </exclude>
    </whitelist>
</filter>

Answer 53 · 2017-03-09T19:58:54.000Z

@GrahamCampbell @taylorotwell can we re-open this?

Answer 54 · 2017-03-16T05:58:13.000Z

Just to add my fix in case it helps anyone:

Laravel 5.1.45
PHPUnit 4.8.35
PHP 5.5.9
Xdebug 2.2.3

I stepped through PHP_CodeCoverage to find that an exception was being thrown in getData() on the call to addUncoveredFilesFromWhitelist(). A twitter exchange from @s_bergmann suggests:

@user1: In @phpunit, what’s the difference between addUncoveredFilesFromWhitelist="true" and processUncoveredFilesFromWhitelist="true" ?
@s_bergmann: You want to use processUncoveredFilesFromWhitelist. If it does not work (legacy code) then use addUncoveredFilesFromWhitelist

(from http://stackoverflow.com/questions/29041254/phpunit-coverage-what-is-the-difference-between-adduncoveredfilesfromwhitelist)

So changing phpunit.xml from:

<whitelist processUncoveredFilesFromWhitelist="true">

to:

<whitelist addUncoveredFilesFromWhitelist="true">

And I've got code coverage back with no exception. Not totally sure what I've lost, but the end result looks complete to me.

Answer 55 · 2017-03-22T05:40:53.000Z

I had the same error few times and in my case it was always issue with missing or not writable directory for coverage files.
As I'm using fastest lib for parallel the snippet can look odd, but it still shows the case you can reproduce without the lib.
find test -name '*Test.php' | vendor/bin/fastest -p4 -o -n "vendor/bin/phpunit {} --coverage-php cov/fastest/{n}.cov;" -vvv

I know issue is closed, but wanna leave a trail in case of someone else having similar issue in the future.

Answer 56 · 2017-05-02T02:53:13.000Z

@GrahamCampbell @taylorotwell can we re-open this?
I'm also still seeing this issue. PHPUnit 6.0.13 by Sebastian Bergmann and contributors.

Runtime: PHP 7.1.3 with Xdebug 2.5.0
Configuration: /home/rof/src/bitbucket.org/waypointbuilding_team/toto/phpunit.ci.xml

...........E

Time: 10.05 seconds, Memory: 14.00MB

There was 1 error:

App\Waypoint\Tests\Api\ClientAdmin\BomaClientCategoryApiTest::it_can_create_boma_client_categories
PHPUnit\Framework\Exception: PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:873
Stack trace:
#0 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(725): Illuminate\Container\Container->notInstantiable('Illuminate\Cont...')
#1 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(598): Illuminate\Container\Container->build('Illuminate\Cont...')
#2 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(567): Illuminate\Container\Container->resolve('Illuminate\Cont...')
#3 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(708): Illuminate\Container\Container->m in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 873
PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:873
Stack trace:
#0 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(725): Illuminate\Container\Container->notInstantiable('Illuminate\Cont...')
#1 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(598): Illuminate\Container\Container->build('Illuminate\Cont...')
#2 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(567): Illuminate\Container\Container->resolve('Illuminate\Cont...')
#3 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(708): Illuminate\Container\Container->m in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 873

ERRORS!
Tests: 12, Assertions: 237, Errors: 1.

Answer 57 · 2017-05-12T20:40:37.000Z

I was running into this as well. I have no idea what was causing it but I eventually found a way around it.

If I removed the backupGlobals="false" from the phpunit.xml file I no longer ran into the error.

Answer 58 · 2017-05-29T05:44:47.000Z

same issue here.

@bmitch tried your solution. but still no luck.

"phpunit/phpunit": "~5.0",

Answer 59 · 2017-05-29T18:03:20.000Z

@sameernyaupane Since I wrote that I've been having luck on and off. I ended up running each PHP Unit test as an isolated process and that fixed it. Takes longer for the tests to run but at least they now all run.

Answer 60 · 2017-09-06T22:31:08.000Z

Laravel 5.4.32
PHP 7.1.5
Xdebug 2.5.3
PHPUnit 5.7.21

Ran into this issue while running code coverage through a Docker container, turned out to be a permissions issue FWIW

Answer 61 · 2017-09-07T00:35:07.000Z

It works fine on my PC, breaks on CircleCI.

L5.4
PHP 7.x
Xdebug 2.5.3
PHPUnit 6.x (PC) and 5.x AND 6.x (CircleCI)

Answer 62 · 2017-09-15T16:08:35.000Z

Having the same issue with:
Behat: 3.4
PHP 7.0.x
Xdebug 2.5.5

Answer 63 · 2017-10-02T08:43:29.000Z

Changing processIsolation="false" to processIsolation="true" fixed this issue for me as well. Now I see the real error of the test.

PHPUnit 5.7.22
PHP 7.1.10
Laravel 5.4.36

Answer 64 · 2017-10-08T14:56:36.000Z

I have the same issue with:
PHPUnit 6.4.1
PHP 7.1.3
Laravel 5.5.14
Homestead 2.1.0

In my case, I want to test for SoapFault errors. I have an instance of a SoapClient with an invalid WSDL URI:

try {
    $client = new \SoapClient('http://example.com/invalid/wsdl', ['exceptions' => true]);
    $client->foo('bar');
} catch (SoapFault $e) {
    // the exception is being caught and reported successfully
    // SOAP-ERROR: Parsing WSDL: Couldn't load from ...
    report($e);
}

However, the SoapClient raises a E_ERROR even with the 'exceptions' => true option.
This is probably a bug in PHP, but the issue here is how that error is handled by Laravel.

Upon inspection, here are the steps in chronological order:

The test execution starts.
The SoapClient raises a SoapFault exception, which is being caught and reported as intended.
The SoapClient raises an error (E_ERROR), which is displayed on the console output, with the same message as the exception.
The test is green, and the assertions are passing.
The tearDown method of Illuminate\Foundation\Testing\TestCase is being invoked.
App@flush()is called, which also calls Container@flush.
The bindings and instances of the container are emptied. As a result, the application's exception handler and the binding for the Illuminate\Contracts\Debug\ExceptionHandler::class are gone. This is important.
After PHPUnit exits (succesfully), PHP's register_shutdown_function is called, and it invokes Illuminate\Foundation\Bootstrap\HandleExceptions@handleShutdown.
Now Laravel is checking for a error_get_last(), and will handle any fatal error.
Since the SoapClient generated an E_ERROR, it will be now converted to a FatalErrorException and passed to HandleExceptions@handleException.
At this point there is a try/catch statement which attempts to report the exception. This will call getExceptionHandler, which resolves the exception handler contract from the container. But since step 7, there is no exception handler, so the container throws a BindingResolutionException.
The catch statement does nothing, and the script continues to call renderForConsole, which again tries to get the exception handler from the container. There is no try/catch there, so this is why everyone is seeing a BindingResolutionException error.
The BindingResolutionException is being handled in the handleException method because of the set_exception_handler, which makes the steps 11-12 to recur. That's why the exception is shown twice on the console.

IMO, Laravel maybe Laravel should try to handle unhandled errors (get_last_error), before the application is flushed. We have beforeApplicationDestroyedCallbacks being called just before flushing, so maybe somewhere in the setUp we should register a callback to handle those errors before shutdown.

Answer 65 · 2017-10-11T14:13:36.000Z

Same issue, processIsolation="false" to processIsolation="true" didn't fixed it for me, but allows the tests to keep running. I can get the specific exception causing it with XDebug.

with :
PHPUnit 6.3.0
PHP 7.0.10
Laravel 5.5.9

and :
PHPUnit 6.4.1
PHP 7.0.10
Laravel 5.5.14

Answer 66 · 2017-10-17T10:15:35.000Z

Same issue, phpunit errors not showing, changing the processIsolation doesn't change anything either.

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /var/www/lbv/vendor/laravel/framework/src/Illuminate/Container/Container.php:918

Vagrant environment:
PHPUnit 6.4.2
PHP 7.1
Laravel 5.5.16

Answer 67 · 2017-10-25T07:16:39.000Z

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/crm-application/vendor/laravel/framework/src/Illuminate/Container/Container.php:918

PHPUnit 6.4.3
PHP 7.1.0
v5.5.18

Answer 68 · 2017-10-26T09:21:52.000Z

Same here:

PHPUnit 6.4.3
PHP 7.2.0RC5
Laravel v5.5.19

Answer 69 · 2017-11-15T14:28:03.000Z

Laravel 5.5.21
phpunit 6.4.4

I've managed to resolve this, but it was related to a mistake in my tests.

You could use XDebug and trace your exception, since this error is only a consequence of some other error.

Answer 70 · 2017-12-29T10:24:58.000Z

I transferred vendor/bin/phpunit and phpunit.bat to the root directory of my project and edited the .bat file to fix the path to /vendor/phpunit/phpunit and it works fine for me now.
(TEMPORARY WORKAROUND)

Answer 71 · 2018-01-07T02:51:05.000Z

Hi, I'm running:

Laravel Framework 5.5.25
PHP 7.2.0-1+ubuntu16.04.1+deb.sury.org+1
Zend Engine v3.2.0
    with Zend OPcache v7.2.0-1+ubuntu16.04.1+deb.sury.org+1
    with Xdebug v2.6.0beta2-dev
    with blackfire v1.18.0~linux-x64-non_zts72

and it throws an exception when creating code coverage report

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/ApoiadorDigital/api.apoiadordigital.com.br/vendor/laravel/framework/src/Illuminate/Container/Container.php:918

any suggestions?

Answer 72 · 2018-03-23T14:27:46.000Z

I got the problem when an exception was thrown in tearDownAfterClass.

Windows 10 x64
PHP 7.0.15-nts-x64
PHPUnit 4.8.16
Laravel 5.1.23

Answer 73 · 2018-03-26T19:04:53.000Z

@casperbakker oh the joys of development. Ironically for me changing processIsolation from true to false fixed it. Honestly.

Answer 74 · 2018-05-28T07:30:26.000Z

I can't for the life of me figure out why my solution works, I came upon it by trial and error. I suspect something is getting serialized improperly and/or handled by-reference having some weird effect. But I've found this to get triggered when the $arguments array in the PHPUnit\TextUI\TestRunner::doRun() method ends up resolving to literally the word "array" with a bunch of single quotes surrounding it.

The solution for me, was go to line 546 and add the following:

$originalArguments = $arguments;
$suite->run($result);
$arguments = $originalArguments;

From what I can tell, neither the content of PHPUnit\Framework\TestSuit::run() nor $result should have any bearing on $arguments whatsoever, but somehow, this fixes the problem. If anyone else has any insight on this, please let me know.

Also, part of how I tracked this down was by replacing the instantiation call within Illuminate\Foundation\Bootstrap\HandleExceptions::getExceptionHandler() from the abstract ExceptionHandler::class to the concrete $this->app->make(\App\Exceptions\Handler::class, ['container' => $this->app]). (The $this->app parameter became necessary as the resulting error claimed that Container was not instantiatable otherwise.)

Once I did that, I got past the BindingResolution error, and moved on to a warning stating that the "failedOrRisky" key on the $arguments "array" was an invalid key reference (because by then, $arguments was actually a string). So to add to all the strangeness of this error, my solution above not only fixed this warning, it removed the need for that class-reference workaround and addressed the initial BindingResolution error as well.

Answer 75 · 2018-05-28T20:06:51.000Z

If changing processIsolation=false don't work, you can try with this solution:

$app->singleton(
    Illuminate\Contracts\Debug\ExceptionHandler,
    DummyApp\Exceptions\Handler
);

Another problem can be a library for PHPUnit, on my case, was codedungeon/phpunit-result-printer 0.25.*

Answer 76 · 2018-06-27T20:41:53.000Z

Writing in to say that this error pops up (after a timeout) on dusk in laravel 5.6 on 'some' browser tests.

Have been breaking my head on fixing this for days until I found this. It was fixed after changing processIsolation to true.

May I propose using processIsolation true on default? Does that make sense?

Versions:

laravel 5.6
dusk 3.0.9
phpunit 7.2.6

Answer 77 · 2018-06-27T21:05:49.000Z

As a followup. I found that adding

/**
 * @preserveGlobalState disabled
 */

to DuskTestCase works as well, but has WAY better performance than enabling processIsolation.

Answer 78 · 2018-07-19T23:28:57.000Z

I have the same problem in the bitbucket pipelines. I'm using the following versions

Laravel 5.6
Dusk 3.0.9
PHP 7.1.18

Answer 79 · 2018-10-18T14:24:08.000Z

I have this issue. I've had no issues under ubuntu 16 + php.7.0 + laravel 5.5, but now under ubuntu 18 it seems to non-deterministicly break php artisan dusk (running all tests). Maybe 50% of the time it won't make it to the end to show me the results because this exception is thrown. Under ubuntu 18 I've tried both php7.2 and php7.0. I've updated to laravel 5.7 and still have this issue.

Answer 80 · 2018-10-31T19:42:50.000Z

@dinandmentink i have exact same issue with dusk can you tell me where to add that exactly ?

i.e. before prepare or driver or newbrowser method ?

Answer 81 · 2018-12-23T19:08:08.000Z

Ping @taylorotwell
Merciful, God, what kind of begging/bribery/weeping will get this fixed? This issue has beet floating around for years now.Would setting up a Crowdfunder.com help???

Now I gotta go into work Wednesday and explain to my boss, who is not an open-source fan, why it took days to find a trivial error in my config file.

OK (36 tests, 2155 assertions)

Generating code coverage report in PHP format ...PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:895
Stack trace:
#0 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(735): Illuminate\Container\Container->notInstantiable('Illuminate\Cont...')
#1 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(608): Illuminate\Container\Container->build('Illuminate\Cont...')
#2 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(575): Illuminate\Container\Container->resolve('Illuminate\Cont...')
#3 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(728): Illuminate\Container\Container->make('Illuminate\Cont...')
#4 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(159): Illumin in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 895
PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:895
Stack trace:
#0 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(735): Illuminate\Container\Container->notInstantiable('Illuminate\Cont...')
#1 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(608): Illuminate\Container\Container->build('Illuminate\Cont...')
#2 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(575): Illuminate\Container\Container->resolve('Illuminate\Cont...')
#3 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(728): Illuminate\Container\Container->make('Illuminate\Cont...')
#4 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(159): Illumin in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 895

Answer 82 · 2018-12-23T23:24:00.000Z

@jschlies you are free to fix the problem and submit a pull request, also you can contribute with the laravel framework before come here with ironies...

Answer 83 · 2018-12-23T23:52:10.000Z

@jschlies I second what @iget-master said. None of the contributors to Laravel or to other open-source projects are being paid for their efforts. Nor do they owe you anything. It's one thing to ask for help, but another to demand that they fix something for you, especially with the tone you used.

Tell your boss there's a problem with a thing on the internet and the only way to fix it is to do some stuff. And if he doesn't that, tell them they're free to get the Oracle solution for $1 billion plus a lifetime support contract.

Answer 84 · 2018-12-24T02:37:58.000Z

Love beautiful code? Yea.
I have nowhere near the skill, experience or access to internal documentation/procedures/architecture to even begin to start to address this or even explain what's going on. What exactly in a container?? What's a BindingResolution and why does it have a special exception. I dunno.
I'm not asking for a major enhancement to be delivered tomorrow. I'm asking that a CLEARLY well documented (multiple times), two year old bug to be addressed within the next year (yea, I'd be happy with that).
I'm just a poor sap that picked Laravel thinking that this type of bug would be addressed by the Laravel eco-system.

Answer 85 · 2018-12-24T03:05:57.000Z

@jschlies

Get with the flow of things or don't use the free software at all. Why are you feeling so entitled that a bug needs to be addressed in the next year or even the next 10 years when you're using what they develop for free?

There's documentation for the api, framework and you can just read the source code itself to see how everything works. Not everyone who contributes back to the framework knows how every single part of the framework works.

Does the bug affect you? yes? Is the bug a major breaking problem? yes? no? Make a report, wait for it to be fixed. Can't wait for it? Fix it yourself or use a different framework. Your tone in your posts are really way off, expecting people to fix things for you.

Answer 86 · 2018-12-26T16:57:18.000Z

My earlier comment got buried, but I have to refer you to it again.
#10808 (comment)
Sorry, I really don't mean this to sound like horn tooting, it's certainly not a pure fix, just a workaround. But I do believe it could spare some folks some significant headaches if you're more interested in pushing past this issue than actually working it.

Also, never offer a tool blind faith, no matter how good. Neither open-source nor proprietary, nor even the scripting language itself will be without bugs. Besides, PHPUnit is framework-agnostic. This may not even be in the scope of Laravel to fix here, we could be taking this up in the wrong forum.

Answer 87 · 2019-01-24T16:09:48.000Z

I'm on php7.2 and laravel 5.7 now and it's still happening.

possibly related, chrome driver has this output:

$ ~/chromedriver-linux 
Starting ChromeDriver 2.35.528139 (47ead77cb35ad2a9a83248b292151462a66cd881) on port 9515
Only local connections are allowed.



[1548345398.028][SEVERE]: Timed out receiving message from renderer: 300.000
[1548345398.030][SEVERE]: Timed out receiving message from renderer: -0.002
[1548345698.035][SEVERE]: Timed out receiving message from renderer: 300.000
[1548345698.037][SEVERE]: Timed out receiving message from renderer: -0.002
[1548348592.400][SEVERE]: Timed out receiving message from renderer: 300.000
[1548348592.403][SEVERE]: Timed out receiving message from renderer: -0.003
[1548348892.409][SEVERE]: Timed out receiving message from renderer: 300.000
[1548348892.411][SEVERE]: Timed out receiving message from renderer: -0.002
[1548352791.671][SEVERE]: Timed out receiving message from renderer: 300.000
[1548352791.673][SEVERE]: Timed out receiving message from renderer: -0.002
[1548353091.676][SEVERE]: Timed out receiving message from renderer: 300.000
[1548353091.683][SEVERE]: Timed out receiving message from renderer: -0.007

Answer 88 · 2019-03-01T12:15:07.000Z

The workaround of kmuenkel does not work for me on laravel 5.5.45, PHP 7.1.12, PHPUnit 6.5.14, dusk 2.0.14. Neither does process isolation true and false work for me. But i created a workaround that does work for my situation. First extend you dusk test case. Then add this method on your test case:

    /**
     * Manual exception handling for when Illuminate\Contracts\Container\BindingResolutionException
     * occurs
     *
     * @param \Closure $testCodeClosure
     * @return $this|void
     */
    protected function catchExceptions(\Closure $testCodeClosure) {
        $formatter = new OutputFormatter(true, self::createAdditionalStyles());
        $output = new ConsoleOutput(ConsoleOutput::VERBOSITY_VERY_VERBOSE, $formatter);

        try {
            $testCodeClosure->call($this);
        }
        catch (\Exception $exception)
        {
            $output->writeln('Catched exception: '.$exception->getMessage());
            $output->writeln('Trace: ');
            $output->writeln($exception->getTraceAsString());
        }
    }

When you get the Illuminate\Contracts\Container\BindingResolutionException you could use it like this for example

/**
 * @group Products
 * @test
 */
public function testProduct()
{
       $this->catchExceptions(function() {
            $counter = 0;
            $productName = 'Dusk test product ' . mt_rand(0, 99999);
            $this->browse(function (Browser $browser) use ($productName, $counter) {
                $browser->loginAs(User::find(1))
                    ->visit(new ProductsSectionTestPage())
                    ->click('@addButton')
                    ->assertSee('New product');
            });
        });
}

Answer 89 · 2019-07-11T12:06:41.000Z

i started getting this when i am using a new vps for gitlab runner running php artisan dusk

hope someone will find fix for it.

and as some more people facing issue, isn't time to make issue "open" ?

thanks.

Answer 90 · 2019-07-12T02:55:26.000Z

I got the same issue.

I try to catch exception when TestRunner is generating coverage

/vendor/phpunit/phpunit/src/TextUI/TestRunner.php

$this->printer->write(
    "\nGenerating code coverage report in HTML format ..."
);

try {
    $writer = new PHP_CodeCoverage_Report_HTML(
        $arguments['reportLowUpperBound'],
        $arguments['reportHighLowerBound'],
        sprintf(
            ' and <a href="https://phpunit.de/">PHPUnit %s</a>',
            PHPUnit_Runner_Version::id()
        )
    );

    $writer->process($codeCoverage, $arguments['coverageHtml']);

    $this->printer->write(" done\n");
    unset($writer);
} catch (PHP_CodeCoverage_Exception $e) {
    $this->printer->write(
        " failed\n" . $e->getMessage() . "\n"
     );
} catch (Exception $e) {
    dd($e);
}

and got error message:

Could not write to coverage/index.html: failed to open stream: Permission denied

After change coverage directory permission to 755 from 555, It's work.

Hope helpful.

PHP: 5.6.25
Laravel: 5.2
PHPUnit:4.8.36
Xdebug: 2.5.5

Answer 91 · 2020-08-11T18:59:56.000Z

This was happening for me, and it ended up being a permissions problem.

Answer 92 · 2020-10-08T16:02:02.000Z

I just wanted to bring up I was also dealing with this issue, but it was due to me using app_path() to reference a custom commands directory, and not __DIR__ like comes in the default Kernel.php

Hope that helps someone

Answer 93 · 2020-10-15T19:26:29.000Z

If you don't need/use varnish Authentication, removing the following files in app\Http\Controllers\Auth:

ForgotPasswordController.php
NoGuestForgotPasswordController.php
RegisterController.php
ResetPasswordController.php
VerificationController.php

"may" solve your problem... "maybe".

Or if you use them check that you have the package "laravel/ui"
In Laravel 7, laravel introduced "laravel/ui" package and they moved some of code from core to "laravel/ui".

And don't use process-isolation as your tests will be slow as hell.

Answer 94 · 2021-03-23T07:09:54.000Z

Hey good people.

This worked for me.

I followed the instructions above at 510725404 and received the following exception dump:

Generating code coverage report in HTML format ...ErrorException {#10406 #message: "count(): Parameter must be an array or an object that implements Countable" #code: 0 #file: "./vendor/phpunit/php-code-coverage/src/Report/Html/Renderer/File.php" #line: 307 #severity: E_WARNING trace: { ./vendor/phpunit/php-code-coverage/src/Report/Html/Renderer/File.php:307 { …} Illuminate\Foundation\Bootstrap\HandleExceptions->handleError() {} ./vendor/phpunit/php-code-coverage/src/Report/Html/Renderer/File.php:307 { …} ./vendor/phpunit/php-code-coverage/src/Report/Html/Renderer/File.php:61 { …} ./vendor/phpunit/php-code-coverage/src/Report/Html/Facade.php:117 { …} ./vendor/phpunit/phpunit/src/TextUI/TestRunner.php:578 { …} ./vendor/phpunit/phpunit/src/TextUI/Command.php:186 { …} ./vendor/phpunit/phpunit/src/TextUI/Command.php:116 { …} ./vendor/phpunit/phpunit/phpunit:52 { …} } }

With:

Laravel 5.4
php 7.4.3
phpunit 5.7.24
xdebug v2.9.2

running Xubuntu 20.04 on Oracle v6.1.16

So I googled the error and found this fix.

And so I changed ./vendor/phpunit/php-code-coverage/src/Report/Html/Renderer/File.php:307

from

$numTests = count($coverageData[$i]);
to

$numTests = count(array($coverageData[$i]));

And the error went away!

This error only appeared when running tests posting logins.

I hope this helps.

Answer 95 · 2021-05-08T03:50:30.000Z

In my case the issue was caused by a psr-0 autoload definition for Facebook SDK 3.2.2 in a legacy app that's running L8 in parallel with ZF1. Definitions are correct in autoload_classmap. It doesn't occur on our servers nor dev workstation only in our GitHub Action which is getting this error when running pest. The unit tests complete and the error occurs soon as the coverage begins in the GIthub Action. For the fix we removed any access to the legacy psr-0 Facebook sdk from the Laravel side and rewrote using Facebook's modern php-graph-sdk. Our legacy unit tests for ZF1 still work properly using the psr-0 version.