You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Test Runner test() method concurrency option should specify "application process" instead of "application thread" #60721
concurrency<number> | <boolean> If a number is provided, then that many tests would run in parallel within the application thread. If true, all scheduled asynchronous tests run concurrently within the thread. If false, only one test runs at a time. If unspecified, subtests inherit this value from their parent. Default: false.
Based on my understanding of the test runner, tests are executed in processes not threads. I think we should update the text here to be specific. Furthermore, I think we should change in parallel with concurrently as unless you are actually executing the tests in separate threads or process its not actually true parallelism. Similar to the way Promise.all() works, right?
I've had these docs cited to me in a claim that Node.js test runner uses worker threads for test execution, when I don't believe that is the case (and if it is then we need different doc updates).
As far as I know, the test runner does not currently use worker threads and never has. I personally never implemented any test runner functionality with worker threads and I don't recall seeing anything merged that uses them.
Individual test files are either executed in separate child processes or the same process as the test runner itself depending on the isolation setting (--test-isolation in the CLI or the corresponding argument to run()). The --test-concurrency flag and corresponding run() argument control how many child processes can execute at a single time.
Individual suites and tests (suite()/describe()/test()/it() calls) are always executed in whatever process the test file is executing in. The Promise.all() comparison is a bit misleading though because the amount of concurrency is configurable and defaults to executing one thing at a time.
If a number is provided, then that many tests would run in parallel within the application thread. If true, all scheduled asynchronous tests run concurrently within the thread.
Should become:
If a number is provided, then that many tests would run concurrently within the test process. If true, all scheduled asynchronous tests run concurrently within the process.
Activity
cjihrig commentedon Nov 15, 2025
As far as I know, the test runner does not currently use worker threads and never has. I personally never implemented any test runner functionality with worker threads and I don't recall seeing anything merged that uses them.
Individual test files are either executed in separate child processes or the same process as the test runner itself depending on the isolation setting (
--test-isolationin the CLI or the corresponding argument torun()). The--test-concurrencyflag and correspondingrun()argument control how many child processes can execute at a single time.Individual suites and tests (
suite()/describe()/test()/it()calls) are always executed in whatever process the test file is executing in. ThePromise.all()comparison is a bit misleading though because the amount of concurrency is configurable and defaults to executing one thing at a time.See here for more details.
azadgupta1 commentedon Nov 15, 2025
Hi! I would like to work on this issue.
I will update the test runner documentation by:
Please let me know if you want any specific wording changes.
Thanks!
Ethan-Arrowood commentedon Nov 17, 2025
@cjihrig yes thats exactly what my understanding is too, except the docs use the word "thread" instead of "process".
You agree we should update the documentation to use the correct terminology?
cjihrig commentedon Nov 17, 2025
I don't have a strong opinion. The current wording isn't technically wrong, but I can also see how it could lead to people thinking the wrong thing.
Ethan-Arrowood commentedon Nov 17, 2025
Should become:
Ethan-Arrowood commentedon Nov 17, 2025
@azadgupta1 if you want to make the change, please go ahead. Please tag me and @cjihrig as reviewers on the PR. Thanks!
pmarchini commentedon Dec 2, 2025
hey @Ethan-Arrowood can we now consider this issue closed? 😁
Ethan-Arrowood commentedon Dec 2, 2025
yes