Inside the Mastering Laravel testing workshop, a student asked a question about running tests on the production server.
I answered the direct question, but then took a step back and explained why I would not recommend running tests on the production server, so I thought it would be worth sharing here on the list as well.
First, I understand the instinct that led to this request. We care most that our production environment works as expected, so there's a certain appeal to actually running tests not just in a production-like environment, but in the actual production environment.
But I think the downsides outweigh any minimal extra bump in confidence we might get from doing this.
The biggest risk is accidentally destroying your production data.
Even with a separate testing database, it only takes one mistake in configuration to have the RefreshDatabase trait wipe out real customer data.
I'm getting the chills just thinking about it.
Beyond that catastrophic risk, you're also expanding your attack surface by installing development dependencies in production. PHPUnit and other testing tools were never designed to be production-safe. Why give potential attackers more code to exploit?
Finally, even if everything goes perfectly, you're consuming production resources to run tests. That CPU and memory should be serving your customers, not validating code that should have been tested long before deployment.
Personally, I put my efforts into making sure local development, the CI pipeline, and even a staging environment all mirror production as closely as possible. That allows me to be confident my tests are catching errors without opening up the risks of running tests in production.
Here to help,
Joel
P.S. Want to level up your testing skills? Check out our Mastering Laravel testing workshop where we cover testing strategies that actually work.