logo

Why we like stopOnError in our test suite

Especially nice for CI pipelines

Joel Clermont
Joel Clermont
2025-10-09

A while ago, I shared why we like stopOnFailure in our test suite.

All the reasons I gave in that post also apply to the stopOnError attribute, so go read that first if you haven't already.

But there's one new thing I bumped into recently that made me appreciate stopOnError even more.

On a client project, a recent Docker configuration change was having a negative impact on our CI pipeline. Each test was having trouble connecting to the database, and it would take several seconds to time out before generating an error and moving on to the next test. This would repeat long enough for the overall Composer script time out to be reached, and only then would the whole CI job fail, and that's assuming you even set a reasonable Composer timeout.

By setting stopOnError to true in my phpunit.xml, the whole test suite now stops as soon as the first test hit a database connection error. No need to burn up more CI pipeline minutes waiting for some higher level timeout to be hit.

I recommend setting both stopOnFailure and stopOnError to true in your phpunit.xml file. It's a much nicer experience.

Here to help,

Joel

P.S. Want to learn how to write effective tests, even in an older untested Laravel app? This is covered in our Laravel testing workshop.

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼
email
No spam. Only real-world advice you can use.