-
Notifications
You must be signed in to change notification settings - Fork 30.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
test_runner: allow running test files in single process #51579
Conversation
Review requested:
|
88d0d08
to
3c85f9a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WIP LGTM
1fa0c69
to
244aa35
Compare
doc/api/cli.md
Outdated
### `--experimental-test-isolation` | ||
|
||
<!-- YAML | ||
added: | ||
- REPLACEME | ||
--> | ||
|
||
When running tests with the `node:test` module, | ||
each test file is run in its own process. | ||
running `--experimental-test-isolation=none` will run all | ||
files in the same process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we maybe make it a feature reserved to run()
? We can always add the flag later, but it seems to me better if we can avoid adding the flag until we know we want to keep the feature along.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to keep the flag as well since I believe this feature makes a lot of sense. I have seen a lot of use cases justifying this:
- typescript, which needs to re-compile per each swpaned process
- setup, for example initializing a server that has a penalty for running again and again per process
and many other variations of this tradeoff
244aa35
to
d9fbc3a
Compare
The
notable-change
Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section. |
d9fbc3a
to
e18b7b9
Compare
Could you please add a test for before/after all hooks and make sure they are not executed multiple times for each file? Couple of thoughts: I think in case of no isolation we should set the If there is concurrency, should it run in different process or same one? |
Can you add a test that we still capture the stdout and sterr correctly? |
e18b7b9
to
3ee9d01
Compare
I'v ended up adding a single process as an entry point for importing all files - this way we support features such as coverage, watch mode, timeout etc. @nodejs/test_runner please take a look. |
@@ -1125,6 +1125,9 @@ changes: | |||
number. If a nullish value is provided, each process gets its own port, | |||
incremented from the primary's `process.debugPort`. | |||
**Default:** `undefined`. | |||
* `isolation` {string} If `'process'`, each test file is run in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* `isolation` {string} If `'process'`, each test file is run in | |
* `isolation` {'process' | 'none'} If `'process'`, each test file is run in |
The tests that I wrote in my prev comment, the implementation detail should not affect the test cases Also, there are some thoughts regarding concurrency that seem like you missed |
can you elaborate? |
Having concurrent test can lead to flaky tests when mutating some global state
Because it can cause flakiness, I would assume concurrency will run in different processes each process won't isolation |
I think it makes sense to document that @MoLow once this lands, do you think it will be feasible to make |
Yes, I think that will be possible. Il try getting back to this PR this week |
I strongly feel this is the responsibility of the test author to ensure they do not create dependencies between tests, and properly manage variables in the global context. I don't think node should have to baby-sit anyone. Jest allows for certain globals, and they make the same very clear in their docs. |
@MoLow are you still planning to work on this? If not, would you mind if I took a shot at it. I'd really like to see this functionality land for the possibilities of a performance boost and avoiding the |
@cjihrig please go ahead 👑 |
Fixes: #51548
this PR is still missing tests & documentation