Nice catch. 👍

This pull request fails (merged a1c7dde into ec13efb).

This pull request passes (merged 42be48a6 into ec13efb).

This pull request passes (merged 8eb083a9 into ec13efb).

This pull request passes (merged 007f97f8 into ec13efb).

Travis is reporting that this is failing, any ideas why?

Apart from that I think this is a good catch, I've not run tasks like this before.

I have no idea why this would fail. I don't yet have the tests installed so I can't run the tests myself, however I suspect it was a one-time glitch while running the tests. I don't know if an exit status of 1 indicates a test failure, or another failure?

I use this method because I have some code which uses exec to start a second php process to run a task in parallel, something like:

exec("php $artisan $task &> /dev/null &");

However, if exec is not available then I run the task directly using Command::run (also easy when testing because then you get any errors in your tasks directly in the browser)

Looks like they had some internal problems there. Usually, you'd expect to see some output from PHPUnit when tests are failing...

Yes, that's what I'm thinking.

Note however that this is a change that affects running tasks themselves, so if this has broken the running of tasks, the test task can't be run either ;)

Just updated from 3.2.3 to 3.2.7 and ran the unit tests, all fine here.

$ php artisan test:core
PHPUnit 3.6.12 by Sebastian Bergmann.

Configuration read from /Users/Joost/Sites/___/phpunit.xml

...............................................................  63 / 248 ( 25%)
............................................................... 126 / 248 ( 50%)
............................................................... 189 / 248 ( 76%)
...........................................................

Time: 3 seconds, Memory: 10.00Mb

OK (248 tests, 567 assertions)

It makes sense to me, let's see if this kills the tests ;)