Background
So, I have a suite of migrations in my app. These migrations run locally for the developers, on our testing server (develop), and on production to build the database up.
Recently I've been trying to repair our migrations so that they run on both SQLite (for feature tests) and MySQL (for the running instances). It was tough. SQLite just isn't built for alter commands.
Anyway, I've been talking about approaches to make it easier. I have heard online and from other developers that most projects don't run their full suite of migrations for tests. This is surprising to me. It seems like if you made migrations that only run on the phpunit database, then you're not really testing the app's flow at all.
Again, I'm not used to the flow of having totally different migrations between Feature Tests and the regular app. In node, C#, and Rust we run the same migrations during feature testing and production.
My Question
-
Do you use your app's migrations for testing, or do you make special migrations just for testing?
-
Since most project apparently have test-specific migrations, what should it look like? How much of my app's schema should I reproduce in these new migrations?
-
How can I be sure that something will work in my test-migration-schema AND my app-migration-schema? If I make a mistake, it seems like something could work during testing but blow up in production (like I name a column different in the testing migrations).