golden zenith
Am I missing something? setUpProcess runs in series for each process that would be set up, so if, for example, you want to migrate a process-specific database for testing, you have to wait for each database to migrate in series.
The tests themselves are running in parallel.
patent nest
Not sure, but I assume it's called from the master process.
I've never heard of process-specific migrations. What's the use case? Maybe it can be solved in a different way.
BTW I'm not sure if the framework is even booted in setupProcess(), which would severely limit what you can do.
golden zenith
The migrations aren’t necessarily process specific in the sense that migrations are different per process, but more each process becomes its own tenant in a multi-tenant system, and each tenant should have its own migrated database.
stray steeple
Not entirely sure what you're referring to, but Laravel does create a database for each process, as per the docs:
As long as you have configured a primary database connection, Laravel automatically handles creating and migrating a test database for each parallel process that is running your tests. The test databases will be suffixed with a process token which is unique per process. For example, if you have two parallel test processes, Laravel will create and use
your_db_test_1andyour_db_test_2test databases.
https://laravel.com/docs/12.x/testing#parallel-testing-and-databases
golden zenith
Sorry for the delay, several meetings.
We have numerous tenants in our application. Each process runs as a separate tenant. The normal process would migrate multiple databases to run the tests on, but not in a multi-tenanted sense.
It would seem intuitive that setup process (or some similar callback) would run on each process, not on the main parent process.