Repository navigation
Expose an id for concurrent test runners (like JEST_WORKER_ID) #55842
Description
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_IDmocha:MOCHA_WORKER_IDvitest:VITEST_POOL_ID
This makes it very easy to set up the proper database connection. For example, here's a snippet from my codebase:
if (process.env.STAGE === "test" && process.env.JEST_WORKER_ID) {
process.env.DB_DATABASE = `myapp_tests_${process.env.JEST_WORKER_ID}`;
}Then, in my database docker container, I create n databases, one for each worker. For example, if I run jest with --maxWorkers 8, I create myapp_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 the TestContext 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 using hooks. I have not dug into this yet.
Activity
cjihrig commentedon Nov 16, 2024
We could add an environment variable fairly easily, but I have a question:
There is already a
NODE_TEST_CONTEXTenvironment variable that can be used to determine that the test runner is being used (if you actually need something like that). Why not use something likecrypto.randomUUID()to create a unique ID for each file?blimmer commentedon Nov 16, 2024
The problem is that, as an external step before the test runner is launched, I:
docker composendatabases (based on the parallelism I run the tests with)node-pg-migrate) against all the test databasesflush_database()function in each test database to runbeforeEachtestI 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
flush_databasefunction to reset database state between tests.So a UUID, for my use case, would not be appropriate. Having a sequential integer between 1 and
n(wherenis the max concurrency) is required for the database setup logic that occurs outside the test runner context.cjihrig commentedon Nov 16, 2024
Got it. Thanks for the explanation. I think we should add support for this.
0hmX commentedon Nov 18, 2024
I can work on this! will pick this up!
cjihrig commentedon Nov 18, 2024
Thanks @cu8code. Please be sure to handle both cases of test isolation. When
--experimental-test-isolation=process, each child process should get an environment variable from 1 to N. When--experimental-test-isolation=none, only the value of 1 should be used.hpatel292-seneca commentedon Nov 22, 2024
Hi @cu8code, are you working on this? If not I can give it a try.
0hmX commentedon Nov 22, 2024
I am working on this 👍
JakobJingleheimer commentedon Dec 1, 2024
Is
worker.threadIdpossibly what you're looking for?blimmer commentedon Dec 1, 2024
We discussed
threadIdin Slack. It's not quite equivalent to what's available in other test runners:18 remaining items
thisalihassan commentedon Jan 15, 2026
I've opened PR #61394 to address this issue.
The PR adds
NODE_TEST_WORKER_IDenvironment variable andcontext.workerIdproperty, which are set based on the test isolation mode:--test-isolation=process(default): Each test file gets a unique worker ID from 1 to N, where N is the concurrency level--test-isolation=none: All tests get worker ID 1 (since they run in the same process)Worker IDs are managed through a pool that allocates and reuses IDs as test files complete, so with 16 test files and concurrency of 8, IDs 1-8 get reused twice.
Why Sequential IDs (1, 2, 3...) vs UUIDs:
I considered using
crypto.randomUUID()as suggested in the comments, but went with sequential IDs for consistency with other test frameworks:JEST_WORKER_ID(sequential)VITEST_POOL_ID(sequential)MOCHA_WORKER_ID(sequential)Sequential IDs also make it easier to pre-allocate resources.
This is available at import time, so it works for module-level initialization without needing to pass context around.
Looking forward to feedback on the implementation!
test_runner: expose worker ID for concurrent test execution
zhanglinqian commentedon Feb 12, 2026
I'd like to work on this issue.
test_runner: expose worker ID for concurrent test execution
test_runner: expose worker ID for concurrent test execution
test_runner: expose worker ID for concurrent test execution
test_runner: expose worker ID for concurrent test execution
test_runner: expose worker ID for concurrent test execution
test_runner: expose worker ID for concurrent test execution
test_runner: expose worker ID for concurrent test execution