Skip to content
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

Document shared modules between tests #64

Open
ethanresnick opened this issue Dec 12, 2022 · 0 comments
Open

Document shared modules between tests #64

ethanresnick opened this issue Dec 12, 2022 · 0 comments

Comments

@ethanresnick
Copy link

Hi, thanks for this awesome package; it has sped up my tests 10x, so I'm very happy with it!!

When I was first considering adopting jest-light-runner, though, one of the things that I most wanted to understand was exactly what type of test isolation I'd be giving up in exchange for the speed boost. I wasn't able to find much documentation on exactly how jest's test isolation works, so I mostly relied on the jest-light-runner README. After playing around with jest and this runner, though, I think this note in the readme is a bit incomplete:

Tests isolation. Jest runs every test file in its own global environment, meaning that modification to built-ins done in one test file don't affect other test files. This is not supported, but you can use the Node.js option --frozen-intrinsics to prevent such modifications.

In particular, from my experiments (please correct me if I'm wrong), it seems like Jest not only evaluates each test file it its own node VM, but also gives each of those VMs a distinct ESM cache (to use when linking modules into the VM), so that mutable ESM exports are also isolated (and re-evaluated) between test files. If that is correct, then it seems important to note that in the README, because --frozen-intrinsics obviously won't flag/prevent mutating module exports.

(As an aside, it might also be worth documenting that --frozen-intrinsics doesn't work with ts-node, I discovered, because the TS compiler sets some properties on the global Error object.)

Anyway, like I said, I think this library is awesome! I'm just opening this issue to double check that my understanding is correct, and, if so, note the confusing bits that I ran into when adopting this library (which did break a few of my tests at first), so that hopefully they can be clarified for future users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant