-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
Expose an id
for concurrent test runners (like JEST_WORKER_ID
)
#55842
Comments
We could add an environment variable fairly easily, but I have a question: if (process.env.STAGE === "test" && process.env.JEST_WORKER_ID) {
process.env.DB_DATABASE = `myapp_tests_${process.env.JEST_WORKER_ID}`;
} There is already a |
The problem is that, as an external step before the test runner is launched, I:
I don't want to do this for each test file because the migration logic is quite slow. It's much faster to migrate once and have a fast So a UUID, for my use case, would not be appropriate. Having a sequential integer between 1 and |
Got it. Thanks for the explanation. I think we should add support for this. |
I can work on this! will pick this up! |
Thanks @cu8code. Please be sure to handle both cases of test isolation. When |
Hi @cu8code, are you working on this? If not I can give it a try. |
I am working on this 👍 |
What is the problem this feature will solve?
When running tests concurrently (the default setting in the Node test runner), it's common practice to split concurrent test runs across multiple local resources (like locally running servers, databases, etc).
Many other popular test runners offer this feature via an environment variable:
jest
:JEST_WORKER_ID
mocha
:MOCHA_WORKER_ID
vitest
:VITEST_POOL_ID
This makes it very easy to set up the proper database connection. For example, here's a snippet from my codebase:
Then, in my database docker container, I create
n
databases, one for each worker. For example, if I runjest
with--maxWorkers 8
, I createmyapp_tests_1
->myapp_tests_8
. During tests, the parallel test suites talk to a different database to avoid deadlocks.What is the feature you are proposing to solve the problem?
The simplest solution for users coming from other frameworks would be to provide an environment variable just like the other test runners (e.g.,
NODE_TEST_WORKER_ID
).However, if that's not feasible, adding a
workerId
to theTestContext
could also be a good solution. This solution is not as ideal as the environment variable because people would need to pass the test context to whatever establishes their db/server/etc connection. In my case, at least, this would require refactoring of code. Right now, I rely on that variable being set at file import time.What alternatives have you considered?
I considered trying to find a solution based on
pid
, but it's not reliable enough. @RedYetiDev mentioned in Slack that there might be a solution usinghooks
. I have not dug into this yet.The text was updated successfully, but these errors were encountered: