@shez1983 if I turn off RefreshDatabase then my tests will fail as each is written/expected to run separately.

I haven't used Valet however if I do run the tests from my host machine - which I think would be the same as running them using Valet. (FYI macOS Sierra 10.12.6 with PHP7.1 installed) then I have the same issue.

@dmhamilt I don't see how that would help, and anyway, it is set to log by default.


I got my tests to run 2-3 times faster by uninstalling xdebug extension

$ brew remove php71-xdebug
7 months ago (727,800 XP)

@arukomp that makes sense. Composer takes a really long time when xdebug is enabled as well. Good find!


you can use transaction trait instead - try that..


here's something for switching xdebug on/off if you've installed PHP through Brew:



sed -i.default "s/^;zend_extension=/zend_extension=/" /usr/local/etc/php/7.1/conf.d/ext-xdebug.ini

launchctl unload /Library/LaunchDaemons/homebrew.mxcl.php71.plist
launchctl load /Library/LaunchDaemons/homebrew.mxcl.php71.plist

echo "xdebug enabled"



sed -i.default "s/^zend_extension=/;zend_extension=/" /usr/local/etc/php/7.1/conf.d/ext-xdebug.ini

launchctl unload /Library/LaunchDaemons/homebrew.mxcl.php71.plist
launchctl load /Library/LaunchDaemons/homebrew.mxcl.php71.plist

echo "xdebug disabled"

don't forget to chmod +x /usr/local/bin/*able-xdebug

$ enable-xdebug
$ disable-xdebug

if brew's PHP is running under the root user, don't forget to add sudo before these commands



Did you try to clear your config cache? Minutes ago I"ve experienced the same issue and clearing the cache solved it. I'm using PHP 7.2 and Laravel 5.5.

1 week ago (13,110 XP)

For those who are running PHP 7.2, I had to do this to remove xdebug:

pecl uninstall xdebug

Then I had to edit my php.ini file and remove the two lines. Once I did that, the speed of my test suite went from ~25 seconds down to 8.


In my case disabling Xdebug sped up tests by 50%. Since I am using Homestead, all I need to do it:


When I run a full test suite.

5 days ago (64,150 XP)

Don't remove x-debug if you need it, thats nuts, just disable it and any other extraneous php_ini add-ons while in unit test. add -n to your flags

here are some aliases to help out from my .bash_profile if you run your commands in the terminal.

alias c='clear'

alias phpspec='c;vendor/bin/phpspec'
alias phpunit='c;vendor/bin/phpunit'
alias p='c;php -n vendor/bin/phpunit --exclude-group external'
alias pf='c;php -n vendor/bin/phpunit --exclude-group external --filter '
alias pext='c;php -n vendor/bin/phpunit'
alias pextf='c;php -n vendor/bin/phpunit --filter '

Use the advice above, I extend DBTestCase a file with RefreshDatabases Trait and a bunch of other macros and hacks I need for testing features, for unit tests just extent regular test case so you don't run migrations when you don't need to.

Add an annotation like @external to tests that can't be rushed, like talking to an external payment gateway when you aren't mocking one out or any external service you can't rush like a fax server etc.. Once you have those running, test them when you need but not when you are doing TDD.

p or pf will run 3-5x faster that phpunit.

if you are using phpstorm, in your Debug Configuration under command line / Interpreter Options: add your -n there too and it should fly again.

HTH Cheers


@Roni Super useful info. In my case though I'm struggling to get the tests running with -n flag.

I had to do this:

php -n -d -d -d -d -d vendor/bin/phpunit

to start with, and got into this error:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/vagrant/code/myproject/vendor/laravel/framework/src/Illuminate/Database/Schema/Blueprint.php on line 1251

somewhere in the middle of my test suite.

Tests seem to be running faster, but it looks like a lot of my tests depend on specific extensions being enabled. But disabling XDebug for the duration of tests (with xon/xoff in Homestead is a huge improvement anyway.

4 days ago (64,150 XP)

What I prefer to do is add another group for example @needsPHPINI and test it separately. the -n flag removes the php_ini add ons and though you can enable them selectively, it can slow you down.

Then for my TDD cycles I just exclude the groups, unless i'm working directly on that item, and then i typically run only the one test or one class to keep it clean and fast.

I don't have my coding laptop with me but I realized I didn't leave an annotation example

here is a link from a quick google search on stack exchange

but basically

/** @test @needsPHPINI */
public function a_special_test() {
        // presumably doing something that has some special ini file need   


Looking at that error it also looks like it's in a migration... I haven't done it yet, but i have a project I'm going to try it on shortly. Where instead of migrating the whole database I'd choose chunks of it, or set up a testing DB and then use a transaction based approach. Especially for an upgrade project with no tests. It may be faster, but someone with more experience should weigh in on that. But using those approaches may also vastly reduce your set up and tear down times.

Please sign in or create an account to participate in this conversation.