[8.x] Adds an afterRefreshingDatabase
test method
#39978
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Howdy!
This PR adds a new method that can be used in a
TestCase
that usesRefreshDatabase
orLazilyRefreshDatabase
that allows a user to perform work after the database has been refreshed. This can be used for seeding, for example, without worry that such work will negate the usefulness ofLazilyRefreshDatabase
.Background
I've been working today with an app that uses
LazilyRefreshDatabase
and seeds a bunch of roles and permissions into the database before tests. In order to get around the fact that seeding would negate the benefits ofLazilyRefreshDatabase
, I wrapped the seeding logic in theMigrationsEnded
event.However, this has a couple of caveats:
themsaid/wink
), then this event will fire twice and you'll end up in a heap on the floor crying 😪Implementation
So, instead, why not provide devs with a method that allows them to perform these setup operations at just the right time? This very simply adds an
afterRefreshingDatabase
method to theRefreshDatabase
trait that can be implemented if desired to put all seeding/after database steps in one place controlled by the framework.The nice thing about this is the fact that it works regardless of which refresh database trait you use, which makes it easier to switch and swap between the two traits depending on use-case.
As always, thanks for all your hard work.
Kind Regards,
Luke