Allow module sandbox to be disabled via configuration

[dzaman]

🚀 Feature Proposal

Extend the resetModule configuration option (e.g. replace boolean with afterTest, [default] afterTestSuite, never) or introduce an additional option (e.g. disableModuleSandbox=boolean) to allow the module sandbox to be disabled with the intent of allowing module state to be shared across test suites.

Motivation / Pitch

As I understand it, one of the major selling points of Jest is that it runs each suite (or test w/ resetModules=true), completely isolated in its own sandbox.

There have been changes to allow more shared state over time (testEnvironment can set globals that are worker-specific; globalSetup has an open feature request to expose the globals it sets in test suites), but module dependencies remain isolated to a single test suite or test.

Jest has a lot of selling points for my team over Mocha, Jasmine, and QUnit. Test parallelization (mocha-parallel-tests handles parent-child process communication poorly), scheduling, coverage, projects, test matching, and expect are all interesting to us.

However, we haven't found a way to use Jest* because the majority of our tests are integration tests that depend on several parts of our application having been loaded and initialized -- a process that takes several seconds. With thousands of such tests, our test suite would jump from 4m30s in a single process to 30 minutes with 7 workers.

* - short of forking Jest or employing the method described below

There is one potential hack that we could use here:

• Create a custom testEnvironment
• In the first call to setup(), initialize a module-scoped variable that we leak as a global into subsequent setup() calls

This would allow us to expose an already-initialized instance to each suite as a global, and we could take things a step further by hijacking require() calls within our application, caching the result of these calls, shoving them into a global that is pushed onto a module scoped var and shared with the next Environment object we set up, with the intention of re-creating the non-isolated require() behavior we have with Mocha.

With this said, we'd love to just disable the require sandbox for tests whose dependencies take prohibitively long to re-intitialize on a per-suite basis. We're not alone in this desire, and we'd be happy to PR it.🤞

I understand this may be flatly rejected as antithetical to Jest's core philosophy, but allowing this to be configured seems essential to make Jest more suitable for a broader spectrum of testing use cases.

[cpojer]

Thanks for adding this proposal. As you stated, there is a good reason to add this feature and it would significantly help you with your test runs. However, adding such a feature would likely lead to downstream effects in the Jest ecosystem that would make everything worse. For example, people may release third party plugins that depend on this behavior, causing more and more projects to opt out of sandboxing. I do not think that is the right way forward for Jest.

I think the best solution for you is to use a custom test runner and piecing the things together that both support your type of setup process and run tests quickly. With the multi runner you can opt either all or only specific tests into this test runner, and keep the regular sandbox for all other tests.

[skitterm]

I think this approach could be viable as a “mode”, and then devs could configure to have the “sandbox mode” or not. In my case, the performance gains Jest offers (running tests in parallel, and sandboxed), are more than negated with the cost of running the same setup script for each test file (my setup script by necessity requires 3rd-party modules).

For me, the performance issues are the dealbreaker, so if there were ways to ameliorate these with a mode that people could use to immediately improve performance, I think it would make Jest that much more bulletproof for a lot of people.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.