Why we use phpunit.xml

Instead of different env files

Joel Clermont
Joel Clermont

Recently, we were joining a project, and part of our onboarding process was to get the test suite into shape.

We have some test helpers and organization structure we like to use, so we adapted the existing suite to follow our established patterns.

During code review, the client asked why we were using phpunit.xml to configure the environment instead of a .env.testing file.

In general, my preference is to do things "the Laravel way", that is to follow established conventions. It just makes it easier to maintain long-term and for other devs to work on the project. And this principle extends beyond Laravel to other tools we use, including PHPUnit.

So while Laravel supports swapping in a specially-named environment file like .env.testing, PHPUnit already gives us an established way of configuring our test runner. In this case, I default to using the tool's conventions.

Another reason I prefer this approach is that Laravel will completely swap in the .env.testing file, and not merge it with the default environment like PHPUnit does. So if you have a .env.testing file, you have to remember to keep it in sync with your .env file, and it's less obvious what you're actually overriding. By using phpunit.xml for configuration, it doesn't have the drift problem and is more explicit about what you're changing.

Here to help,


P.S. Would you like help getting your test suite into shape?

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼

Level up your Laravel skills!

Each 2-minute email has real-world advice you can use.