Description
🚀 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 subsequentsetup()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.