Fixed up the phpunit config #3725

GrahamCampbell · 2016-03-30T18:52:18Z

We'll need to update the docs to let people know about this.

taylorotwell · 2016-03-30T23:51:20Z

Can you describe more what was going on and what this fixes?

shehi · 2016-03-31T06:59:00Z

I personally see only cosmetic changes there. He just added suffix for test files which is useful when you have some non-test file there. 👍

scrubmx · 2016-03-31T07:54:17Z

@taylorotwell @shehi I think this fixes laravel/framework#10808

shehi · 2016-03-31T07:57:47Z

@scrubmx Can't be! The cause for that problem can't be THIS SIMPLE! /runs to test it

UPDATE: You know what's weird? I don't know who did what, but right now, all my tests run smoothly with PHPUnit-5, without this change. I don't know how.

UPDATE-2: How part = I don't have routes.php files in my app, it's all inside RouteServiceProvider. That's why I stopped receiving these errors.

GrahamCampbell · 2016-03-31T09:22:34Z

I personally see only cosmetic changes there.

Not at all!

Can you describe more what was going on and what this fixes?

Because our routes.php file is not PSR-4 compliant, we can't safely "require" it. PHPUnit's code coverage will attempt to require all files as if they have no "consequences", but our routes file will execute code when you require it. That fact means that when PHPUnit goes through the stages of checking for uncovered files, it will require the routes file directly, thus causing this exception.

NB This error will only happen if your test suite doesn't require the routes file itself at one point. So, if you don't have any tests that boot the routing layer, then you'll see the bug, or, if you ran a subset of your tests that don't load the routes file, you'll see this error.

GrahamCampbell · 2016-03-31T09:23:25Z

phpunit.xml

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


this is the really important change - it is NOT cosmetic - it stops phpunit requiring this file when searching for uncovered files

I retract my statement of it being cosmetic :D LOL, thanks for awesome solution.

Shouldn't we just exclude ./app/Http/routes.php file without introducing other changes (we could make that the new default on 5.3)

Why are we so concerned about breaking BC in the app skeleton? Do people actually update their existing apps? How?

I have Laravel-5.2 based code (AudithSoftworks/Basis) and I always have
it up-to-date with the latest Laravel. I update it to the letter, as far
as I can, unless those updates are not necessary due to my own
modifications.

On 01-04-2016 08:03, Joseph Silber wrote:

In phpunit.xml
#3725 (comment):

</testsuite> </testsuites> <filter>

<whitelist>

<directory suffix=".php">app/</directory>

<whitelist processUncoveredFilesFromWhitelist="true">

<directory suffix=".php">./app</directory>

<exclude>

<file>./app/Http/routes.php</file>
Why are we so concerned about breaking BC in the app skeleton? Do
people actually update their existing apps? How?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/laravel/laravel/pull/3725/files/28ea52d10b69b5cdf6fe72fe2acb5594022e1a8e#r58162725

I'd recommend adding some kind of XML comment into that file, notifying
users. We have comments everywhere, why not in this file as well?

On 01-04-2016 07:02, Mior Muhammad Zaki wrote:

In phpunit.xml
#3725 (comment):

</testsuite> </testsuites> <filter>

<whitelist>

<directory suffix=".php">app/</directory>

<whitelist processUncoveredFilesFromWhitelist="true">

<directory suffix=".php">./app</directory>

<exclude>

<file>./app/Http/routes.php</file>

Shouldn't we just exclude |./app/Http/routes.php| file without
introducing other changes (we could make that the new default on 5.3)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/laravel/laravel/pull/3725/files/28ea52d10b69b5cdf6fe72fe2acb5594022e1a8e#r58160091

GrahamCampbell · 2016-03-31T09:24:21Z

https://github.com/sebastianbergmann/php-code-coverage/blob/3.3.0/src/CodeCoverage.php#L707

StephenWattbike · 2016-03-31T10:26:39Z

I still get exactly the same error after updating the config file. I am running phpunit 4.8.2, php 7.0 and Laravel 5.2.

Is there a step I am missing? I have run composer dump-autoload & php artisan clear-compiled etc.

GrahamCampbell · 2016-03-31T10:30:29Z

Is there a step I am missing?

There might be other files you need to exclude too that you've added.

StephenWattbike · 2016-03-31T10:31:43Z

Thats actually a very good point, thanks for the tip.

taylorotwell · 2016-03-31T13:07:59Z

What error are y'all even talking about?

StephenWattbike · 2016-03-31T13:46:27Z

I am still working on my phpunit.xml processUncoveredFilesFromWhitelist whitelist, which should fix this error that I get when running phpunit. I think its related to this closed issue: laravel/framework#10808

PHPUnit 4.8.24 by Sebastian Bergmann and contributors.

Runtime: PHP 7.0.3-13+deb.sury.org~trusty+1 with Xdebug 2.4.0RC4
Configuration: /home/vagrant/Code/phpunit.xml

........... 11 / 11 (100%)

Time: 16.74 seconds, Memory: 28.00Mb

PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/Code/bootstrap/cache/compiled.php:1349
Stack trace:
#0 /home/vagrant/Code/bootstrap/cache/compiled.php(1295): Illuminate\Container\Container->build('Illuminate\Cont...', Array)
#1 /home/vagrant/Code/bootstrap/cache/compiled.php(1857): Illuminate\Container\Container->make('Illuminate\Cont...', Array)
#2 /home/vagrant/Code/bootstrap/cache/compiled.php(2175): Illuminate\Foundation\Application->make('Illuminate\Cont...')
#3 /home/vagrant/Code/bootstrap/cache/compiled.php(2144): Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler()
#4 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleException(Object(Symfony\Component\Debug\Exception\FatalThrowableError))
#5 {main}
thrown in /home/vagrant/Code/bootstrap/cache/compiled.php on line 1349

Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/Code/bootstrap/cache/compiled.php on line 1349

Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/Code/bootstrap/cache/compiled.php on line 1349

Call Stack:
16.7483 27003040 1. Illuminate\Foundation\Bootstrap\HandleExceptions->handleException() /home/vagrant/Code/bootstrap/cache/compiled.php:0
16.7857 27022976 2. Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler() /home/vagrant/Code/bootstrap/cache/compiled.php:2144
16.7857 27022976 3. Illuminate\Foundation\Application->make() /home/vagrant/Code/bootstrap/cache/compiled.php:2175
16.7857 27023032 4. Illuminate\Container\Container->make() /home/vagrant/Code/bootstrap/cache/compiled.php:1857
16.7857 27023032 5. Illuminate\Container\Container->build() /home/vagrant/Code/bootstrap/cache/compiled.php:1295

shehi · 2016-03-31T14:26:22Z

@taylorotwell Don't you remember the case when PHPUnit 5 wasn't working in Laravel 5? Well, @GrahamCampbell and the team solved that issue, apparently.

@StephenWattbike , this fix definitely solves the problem we had specifically with PHPUnit 5 (not 4). Not sure if your case is related though. I never had any issues with PHPUnit 4 even when I had routes.php in place, or any other file for that matter. I'd recommend profiling your code and check for every included, required file during the test run.

GrahamCampbell · 2016-03-31T14:28:41Z

I am still working on my phpunit.xml processUncoveredFilesFromWhitelist whitelist, which should fix this error that I get when running phpunit. I think its related to this closed issue: laravel/framework#10808

This fixes that closed issue.

GrahamCampbell · 2016-03-31T14:28:58Z

You'll need to add any other files to the whilelist excludes that are of the same nature as routes.php.

GrahamCampbell · 2016-03-31T14:29:25Z

Not doing so is not a bug in laravel, it's just misconfiguration on you part I'm afraid.

StephenWattbike · 2016-03-31T14:49:16Z

So I should use phpunit 5 to avoid this issue altogether? I think @GrahamCampbell said that only phpunit version 4.8 was supported which is why I'm running that version. I will run 5 if I can avoid this whitelisting which may work for a blank project but its becoming painful for me.

I will continue to try the whitelist with 4.8 but I still get the error after excluding my own additions, and other combinations to get it to work. Sorry to drop in this thread I am trying my best to get past this issue.

GrahamCampbell · 2016-03-31T14:50:57Z

So I should use phpunit 5 to avoid this issue altogether? I think @GrahamCampbell said that only phpunit version 4.8 was supported which is why I'm running that version. I will run 5 if I can avoid this whitelisting which may work for a blank project but its becoming painful for me.

Both are broken.

GrahamCampbell · 2016-03-31T14:51:23Z

Well, neither are broken as long as you configure them correctly...

GrahamCampbell · 2016-03-31T15:26:32Z

I didn't need a whitelist before and now I do. What has changed? also shouldn't the php flag --no-coverage fix this?

So long as code coverage uncovered file searching has been enabled, you have always needed this to prevent this from happening, in all versions.

taylorotwell · 2016-04-01T03:16:41Z

Is it possible this is a breaking change at all?

crynobone · 2016-04-01T03:59:24Z

phpunit.xml

@@ -10,12 +10,15 @@
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Application Test Suite">
-            <directory>./tests/</directory>
+            <directory suffix="Test.php">./tests</directory>


Is it necessary to have this changes?

That one is not necessary, but is more useful.

shehi · 2016-04-01T07:38:30Z

I don't think it can be a breaking change. Noone would go and copy paste
new code change blindly lol. If they do, it's their problem. Shouldn't
and Couldn't be able to hinder the progress....

On 01-04-2016 06:17, Taylor Otwell wrote:

Is it possible this is a breaking change at all?

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

GrahamCampbell · 2016-04-01T09:54:42Z

Nothing made to laravel/laravel is breaking really, like your web middleware changes.

StephenWattbike · 2016-04-01T10:14:00Z

very strange:

if i use:

./vendor/bin/phpunit

I do not get an error anymore, I got the idea from this stackoverflow:
https://stackoverflow.com/questions/34760614/calling-phpunit-is-not-calling-vendor-bin-phpunit

PHPUnit 4.8.24 by Sebastian Bergmann and contributors.
Runtime: PHP 7.0.3-13+deb.sury.org~trusty+1 with Xdebug 2.4.0RC4
Configuration: /home/vagrant/Code/phpunit.xml
.............
Time: 12.21 seconds, Memory: 30.00Mb
OK (13 tests, 198 assertions)

Also I removed the filter stuff from the XML and run ./vendor/bin/phpunit without errors.

crynobone · 2016-04-01T10:18:52Z

Noone would go and copy paste new code change blindly lol. If they do, it's their problem.

The problem with changes on patch release is that when people upgrade from say v5.2.0 (start the project when 5.2 released) to v5.3.0, often these between version changes are left out from upgrading guide. So yes, some including myself always update the skeleton. It helps us not to miss anything (and reduce errors when upgrading major version).

shehi · 2016-04-01T10:25:47Z

Why would you use a piece of code (in this case, the system's phpunit)
over which you have zero control?! Even Xdebug messes up when something
is outside working directory.

On 01-04-2016 13:14, Stephen Wattbike wrote:

very strange:

if i use:
./vendor/bin/phpunit
I do not get an error anymore, I got the idea from this stackoverflow:
https://stackoverflow.com/questions/34760614/calling-phpunit-is-not-calling-vendor-bin-phpunit
PHPUnit 4.8.24 by Sebastian Bergmann and contributors.
Runtime: PHP 7.0.3-13+deb.sury.org~trusty+1 with Xdebug 2.4.0RC4
Configuration: /home/vagrant/Code/phpunit.xml

.............

Time: 12.21 seconds, Memory: 30.00Mb

OK (13 tests, 198 assertions)

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

shehi · 2016-04-01T10:27:08Z

Agreed, that's why I recommended adding inline XML comments. I still am
amazed why noone entertains the idea. Why XML's are any special? Does it
break PHPUnit when you add a comment into phpunit.xml?

On 01-04-2016 13:19, Mior Muhammad Zaki wrote:

Noone would go and copy paste new code change blindly lol. If they
do, it's their problem.
The problem with changes on patch release is that when people upgrade
from say |v5.2.0| (start the project when 5.2 released) to |v5.3.0|,
often these between version changes are left out from upgrading guide.
So yes, some including myself always update the skeleton. It helps us
not to miss anything (and reduce errors when upgrading major version).

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

shehi · 2016-04-01T10:54:57Z

It's hard to debug and control the flow as you debug, which is the
inseparable part of Dev work. And last time I checked, PHPUnit was Dev
tool. Otherwise, yes, they should be the same, unless whoever packaged
it for, let's say Ubuntu, modified it to suit package-manager's needs. I
never trust those packagers personally: had problem with Scala-via-Apt
in past, had problem with Node-via-Apt, and it was nightmare for me to
work via PHPUnit-via-Apt when it came to debugging with XDebug.

Also, wasn't it [!CDATA[ ... ]] blah blah the correct way of commenting
in XML?! Or any PI (processing instruction) would do the trick, via

(the same original reason why PHP had tag

in first place). It's been while since I read XML-Bible, like 6 years
now, so I might be wrong.

On 01-04-2016 13:32, Stephen Wattbike wrote:

Why would you use a piece of code (in this case, the system's phpunit)
is there something magically different between calling: phpunit from
the project route or calling the file ./vendor/bin/phpunit ?
xml comments work fine in the phpunit file.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3725 (comment)

StephenWattbike · 2016-04-01T11:28:01Z

vagrant@homestead:~/Code/vendor/bin$ ./phpunit --version
PHPUnit 4.8.24 by Sebastian Bergmann and contributors.

vagrant@homestead:~/Code$ phpunit --version
PHPUnit 5.3.0 by Sebastian Bergmann and contributors.

When I run phpunit from the project root its using my "system" phpunit
When I run ./vendor/bin/phpunit its using the phpunit inside the vendor folder not the other way round like you suggested earlier @shehi

shehi · 2016-04-01T11:53:34Z

I didn't suggest the other way around. Command "phpunit" uses
system-wide-installed application, whereas "./vendor/bin/phpunit" is
within your application boundaries. This shouldn't need explanation.
What I meant, was that, running it from system-scope/namespace makes
debugging a nightmare. Anyway, I don't even understand why we keep
discussing this email after email :) like a freshman. Let's move on.

On 01-04-2016 14:28, Stephen Wattbike wrote:

vagrant@homestead:~/Code/vendor/bin$ ./phpunit --version
PHPUnit 4.8.24 by Sebastian Bergmann and contributors.

vagrant@homestead:~/Code$ phpunit --version
PHPUnit 5.3.0 by Sebastian Bergmann and contributors.

When I run phpunit from the project root its using my "system" phpunit
When I run ./vendor/bin/phpunit its using the phpunit inside the
vendor folder not the other way round like you suggested earlier
@shehi https://github.com/shehi

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

driesvints · 2016-05-02T11:13:36Z

I still seem to be getting this error. Excluded all stand-alone files in the exclude list. Running PHPUnit 4.8.24.

derrekbertrand · 2016-05-31T07:35:06Z

@driesvints Tested this on a fresh install of Laravel 5.2, and received this error when running the phpunit I installed globally using composer (~/.composer/vendor/bin/phpunit). As mentioned by @StephenWattbike , the error went away when running ./vendor/bin/phpunit.

No idea why this works, but that's for smarter people than me to figure out.

driesvints · 2016-05-31T08:23:20Z

@derrekbertrand it doesn't really matter if you use global or local phpunit but it's a matter of which version you're using I believe. Can you run the following two commands and paste the output here?

phpunit --version
vendor/bin/phpunit --version

derrekbertrand · 2016-05-31T09:05:04Z

@driesvints It may be the case, or it could not... Checking the version of the global binary yields 5.1, but actually running it - it thinks it is 4.8? That's the version Laravel installed! This is some chicanery, but nothing that actually has to do with Laravel.

As you can see, I can reproduce the error every time, however, phpunit may be lying about its version or misconfigured somehow.

Check this out:

derrek@foxglove-0001 ~/projects/test $ phpunit --version
PHPUnit 5.1.4 by Sebastian Bergmann and contributors.

derrek@foxglove-0001 ~/projects/test $ vendor/bin/phpunit --version
PHPUnit 4.8.26 by Sebastian Bergmann and contributors.

derrek@foxglove-0001 ~/projects/test $ phpunit
PHPUnit 4.8.26 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 101 ms, Memory: 10.00MB

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/derrek/projects/test/vendor/laravel/framework/src/Illuminate/Container/Container.php:748
...DUMP...

derrek@foxglove-0001 ~/projects/test $ vendor/bin/phpunit 
PHPUnit 4.8.26 by Sebastian Bergmann and contributors.

.

Time: 99 ms, Memory: 10.00MB

OK (1 test, 2 assertions)

driesvints · 2016-05-31T09:11:27Z

@derrekbertrand that's odd. Although you've confirmed that the problem happens when running at least PHPUnit 4.8.x. Can you run which phpunit to see if you can find the path to the global binary? Afterwards can you try to run the 5.1.4 binary directly with the full path to see if it also happens with that particularly version?

derrekbertrand · 2016-05-31T09:30:18Z

@driesvints Breaks like you'd expect, and gets confused about its version.

derrek@foxglove-0001 ~/projects/test $ which phpunit
/home/derrek/.composer/vendor/bin/phpunit
derrek@foxglove-0001 ~/projects/test $ /home/derrek/.composer/vendor/bin/phpunit
PHPUnit 4.8.26 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 102 ms, Memory: 10.00MB

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/derrek/projects/test/vendor/laravel/framework/src/Illuminate/Container/Container.php:748
...DUMP...

driesvints · 2016-05-31T09:34:06Z

@derrekbertrand super weird :-| Don't know what's going on here.

mihailo-misic · 2016-07-06T16:58:57Z

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'

Hope somebody finds this useful.

GrahamCampbell · 2016-07-06T17:00:29Z

Or just don't globally require PHPUnit.

Fixed up the phpunit config

jpuck · 2017-06-20T16:24:57Z

@GrahamCampbell Is this no longer an issue because it was reverted in 288e361? I would have instead expected the path to be updated to something like:

<exclude>
    <directory>./routes</directory>
</exclude>

I only ask because I'm trying to investigate why code coverage reports are throwing exceptions again in php 7.2 for laravel tests. It doesn't seem to be related to the routes files, but I just thought I'd clarify this particular issue along the way.

Thanks

FatBoyXPC · 2018-01-17T05:24:31Z

The routes directory is outside of app now (currently in L5.5, at least) but I'm still having this problem trying to run code coverage.

PHP 7.2.1
PHPUnit 6.4.3
Laravel 5.5.21
XDebug enabled, 2.6.0beta1

➜  matchdevs git:(master) ✗ vendor/bin/phpunit --coverage-html coverage
PHPUnit 6.4.3 by Sebastian Bergmann and contributors.

........................                                          24 / 24 (100%)

Time: 3.17 seconds, Memory: 26.00MB

OK (24 tests, 67 assertions)

Generating code coverage report in HTML format ...PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php:918
Stack trace:
#0 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php(758): Illuminate\Container\Container->notInstantiable('Illuminate\\Cont...')
#1 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build('Illuminate\\Cont...')
#2 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php(586): Illuminate\Container\Container->resolve('Illuminate\\Cont...', Array)
#3 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(732): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#4 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptio in /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 918
PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php:918
Stack trace:
#0 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php(758): Illuminate\Container\Container->notInstantiable('Illuminate\\Cont...')
#1 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build('Illuminate\\Cont...')
#2 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php(586): Illuminate\Container\Container->resolve('Illuminate\\Cont...', Array)
#3 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(732): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#4 /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptio in /home/james/dev/matchdevs/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 918
➜  matchdevs git:(master) ✗

Fixed up the phpunit config

28ea52d

GrahamCampbell mentioned this pull request Mar 30, 2016

[5.1] [5.2] Error handler hides PHPUnit errors laravel/framework#10808

Closed

GrahamCampbell reviewed Mar 31, 2016
View reviewed changes

crynobone reviewed Apr 1, 2016
View reviewed changes

taylorotwell merged commit 5450b31 into master Apr 1, 2016

GrahamCampbell deleted the phpunit branch April 1, 2016 18:29

antonkomarev mentioned this pull request Apr 26, 2016

PHPUnit_Framework_ExpectationFailedException orchestral/testbench#116

Closed

zachleigh pushed a commit to zachleigh/laravel that referenced this pull request Nov 23, 2016

Merge pull request laravel#3725 from laravel/phpunit

dfb8176

Fixed up the phpunit config

bradsi mentioned this pull request May 6, 2022

BindingResolutionException with --coverage when using pcov pestphp/pest#451

Closed

Fixed up the phpunit config #3725

Fixed up the phpunit config #3725

Conversation

GrahamCampbell commented Mar 30, 2016

taylorotwell commented Mar 30, 2016

shehi commented Mar 31, 2016

scrubmx commented Mar 31, 2016

shehi commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

GrahamCampbell Mar 31, 2016

Choose a reason for hiding this comment

shehi Mar 31, 2016

Choose a reason for hiding this comment

crynobone Apr 1, 2016

Choose a reason for hiding this comment

JosephSilber Apr 1, 2016 via email

Choose a reason for hiding this comment

shehi Apr 1, 2016

Choose a reason for hiding this comment

shehi Apr 1, 2016

Choose a reason for hiding this comment

GrahamCampbell commented Mar 31, 2016

StephenWattbike commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

StephenWattbike commented Mar 31, 2016

taylorotwell commented Mar 31, 2016

StephenWattbike commented Mar 31, 2016

shehi commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

StephenWattbike commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

GrahamCampbell commented Mar 31, 2016

taylorotwell commented Apr 1, 2016

crynobone Apr 1, 2016

Choose a reason for hiding this comment

GrahamCampbell Apr 1, 2016

Choose a reason for hiding this comment

shehi commented Apr 1, 2016

GrahamCampbell commented Apr 1, 2016

StephenWattbike commented Apr 1, 2016

crynobone commented Apr 1, 2016

shehi commented Apr 1, 2016

shehi commented Apr 1, 2016

shehi commented Apr 1, 2016

StephenWattbike commented Apr 1, 2016

shehi commented Apr 1, 2016

driesvints commented May 2, 2016

derrekbertrand commented May 31, 2016

driesvints commented May 31, 2016

derrekbertrand commented May 31, 2016 • edited

driesvints commented May 31, 2016

derrekbertrand commented May 31, 2016

driesvints commented May 31, 2016

mihailo-misic commented Jul 6, 2016

GrahamCampbell commented Jul 6, 2016

jpuck commented Jun 20, 2017

FatBoyXPC commented Jan 17, 2018 • edited

derrekbertrand commented May 31, 2016 •

edited

FatBoyXPC commented Jan 17, 2018 •

edited