-
Notifications
You must be signed in to change notification settings - Fork 11.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[11.x] Add the ability to skip migrations within tests #54441
base: 11.x
Are you sure you want to change the base?
Conversation
Thanks for submitting a PR! Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface. Pull requests that are abandoned in draft may be closed due to inactivity. |
Ability to skip a migration to test it is a good idea, but I think it should be done for test cases without the public function testSomeMigration(): void
{
Migrator::withoutMigrations(['some_migration_name']);
// check stuff in the "old" db state
Migrator::withoutMigrations([]);
// check stuff in the "new" db state
} I think your current implementation would only respect a skip if it happens on the first "refresh" and it would be kept for all other tests. |
Ah, that's a good point. The database doesn't get refreshed from testMethod to testMethod. Thanks for calling it out. Maybe I'll drop the attribute change and just add some tests. 🤷 |
f8f4184
to
8d65bc3
Compare
024466f
to
6f13580
Compare
It is very difficult to test a single migration. By introducing the ability to explicitly skip migrations, we can prepare our database to match a production environment, run the new migration, and confirm that there are no unintended consequences.
Tasks
Follow-ups
Add a
TestsMigration
trait that will simplify the process of testing a migration.Thoughts
It dawned on me that this works for testing a migration for a while, but eventually the codebase may have other migrations that depend on a skipped one. It would require a developer to pull the test once that happens. (Which kind of makes sense, once you've run the test and deployed your migration, the test is kind of useless).
It may be better to have a syntax like
Migrator::noMigrationsAfter('2024_02_02__12_00_00__adduserstable.php')
. This could be added a follow up, or I can add it now. Let me know what you prefer.