🚀 Feature: Way to setup/teardown one resource per MOCHA_WORKER_ID

[jedwards1211]

Is your feature request related to a problem or a nice-to-have?? Please describe.
I wanted to start using parallel mode. In serial mode I have a before() root hook that initializes the database and an after() root hook that does some teardown.
To use parallel mode I want to fan out into one database per MOCHA_WORKER_ID, so if I have two jobs, I just need to setup/teardown a database for MOCHA_WORKER_ID=0 once and setup/teardown a database for MOCHA_WORKER_ID=1 once.
The same goes for isolating redis instances used by my tests. Would be nice if each worker could just start its own redis container, and stop it at the end.
It feels like this should have been easy. Instead, it's been a complete hassle. Even with code changes, I can't figure out any clean way to do it.

Describe the solution you'd like
I'd like to be able to use --file (or something) to pass files with before/after root hooks to every worker, and have them run once per worker. This would have made migrating to parallel mode a total breeze.

The only options Mocha gives me right now are once per file (root hook plugins) or once only (global fixtures).

Describe alternatives you've considered
I can wrap beforeAll with once() to initialize a resource associated with the worker process.
However, I can't wrap afterAll with once() because that will run after the first test file, not after all test files in the worker.

I even tried making each test file import the file with my before/after hooks. But they only seemed to get attached to tests in the first file in parallel mode. It's hard to imagine a reason why it has to behave that way.

Then I thought about making a global fixture that initializes all the databases, but I don't see any documented way to ask mocha how many jobs it will run from the global fixture...argh!

[alaycock]

@jedwards1211 did you find a solution to this?

[JoshuaKGoldberg]

Yeah, I can see why you'd want this. Per #5027 we're trying to limit the number of new features without a large amount of user demand (only ~two people in 11 months doesn't quite qualify). But this would be solved by the plugin API in #1457. Closing this issue out as a subset of that one. Cheers! 🤎

[jedwards1211]

@alaycock not exactly, I ended up fanning out to parallel jobs in CircleCI. I haven't come up with a workaround for running tests in parallel locally.
@JoshuaKGoldberg makes sense, thanks!

[alaycock]

Thanks for the response @jedwards1211, we ended up doing the same thing.