Why we keep the testing database separate

Today's tip was inspired by a conversation in our Slack community.

Someone was bumping into weird issues with migrations when running tests, and part of the problem is that they were using a single database for local development and for their tests.

In the past, I've shared how we set up our tests to use a separate database, but that post is more about the "how". Today, I want to talk about the "why".

There are two main reasons I like using a separate testing database:

First, it frees you up to run your tests as much as you want, without worrying about blowing away your development database.

As you're building a feature, you might have some data set up just the way you want it. Losing that each time you run tests is annoying.

Second, by having your tests run in a separate, empty database, it increases your confidence that the migrations are always working as expected.

I can't tell you how many projects I've joined that have some weird migration drift from what is running in production. This approach keeps you honest.

Separate doesn't mean different though. I don't recommend using SQLite for tests if you're not using it in production.

And this doesn't mean you need two servers, you can have both databases run in a single MySQL server.

Here to help,

Joel

P.S. Join the Mastering Laravel community to get help with your Laravel questions.