Why we use phpunit.xml

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,

Joel

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