Blazing Fast Migrations For Laravel Testing

I recently purchased a course called “PHP Package Development” by @marcelpociot. The course was really good. If you are interested in package development for Laravel apps, I highly recommend it.

After completing the course I decided to take a stab at developing a package. It took me about 4 hours to build the package and upload it to packagist. Which is much less time that I would have predicted before watching Marcel’s course.

Can I Make My Tests Start Faster?

I have an application that has been around for about 4 years now. Over the years, we have added many migration files. Because each of these migration files run before the tests, the time it takes to initialize the database and begin running is about 3-4 seconds.

Snipe Migrations creates a “snapshot” of the database and saves it to a snipe_snapshot.sql dump file. On subsequent test runs Snipe imports the schema to your MySql database, instead of running the migrate command again. This dramatically speeds up the initialization time before tests run.

Since you will need a new snapshot whenever you change or add a migration file. The package keeps track of your migration files and will automatically update the snapshot if anything changes. If you want help with installation or to see how it works, watch the video below.

Why Is It Named Snipe Migrations?

I named the package Snipe Migrations because the Great Snipe is the world’s fastest migratory bird.

If your Laravel tests are starting slowly due to a large number of migration files, check it out. Feel free to make suggestions or PR’s on GitHub.

You can find the package on packagist:

2 replies on “Blazing Fast Migrations For Laravel Testing”

Hi Dustin!

Congratulations on the shipping. I just tested this package and it is working very well!
I was wondering if you were able to enable the snapshot behaviour for the RefreshDatabase trait as well?
Why did you choose to trigger the snapshotting only with the DatabaseTransactions trait?


Hi Mathias. Thanks for your comment. I used the DatabaseTransactions trait because it already handles wrapping each test in a transaction and rolling back after the test runs. Secondly, it doesn’t touch the database. So in my case Snipe handles the database schema setup and DatabaseTransactions handles the transactions.

Leave a Reply

Your email address will not be published. Required fields are marked *