Summer Sale! All accounts are 50% off this week.
I have a test that calls a method that uses a transaction, which means I can't use the RefreshDatabase trait to wrap tests in transactions and roll them back, so for that test I'm using DatabaseMigrations instead. What I see then though is that instead of doing a migrate:fresh, it seems to step backwards through all my migrations calling down() on each of them, and this often fails because some migrations are impossible to reverse. It's also much slower to do this than to throw the whole DB away and start again.
How can I force a test to use a clean, forward-only migration on the DB?
migrate:fresh does not step back through migrations: https://laravel.com/docs/master/migrations#drop-all-tables-migrate it drops all tables and then runs migrate which is what you are looking for.
Try putting this test in another suite of tests and do not run it every time, this way you will not be annoyed with it ;-)
Yes, I know that's what migrate:fresh does – it would avoid all those down() calls, which is why I asked. But it seems that the DatabaseMigrations trait doesn't work that way.
I managed to track down a key problem that had pushed me in this direction: my test contained a Model::truncate() call, which seems to break transactions. Model::query()->delete() doesn't have that effect, but I managed to rearrange things to do without either.
So my tests are now passing, however, I'm not clear how Laravel can nest transactions given that MySQL doesn't support doing that! As far as I can see it's doing this:
...which shouldn't be possible!
Please or to participate in this conversation.