This pattern almost always means hidden shared state or an environment difference.
First, reproduce the failure:
- Run the file alone.
- Run the full suite with
--runInBand. This rules out parallel workers fighting over a database, ports or files. - Use Jest's
--randomizeto shuffle the test order within files. Use--seedto replay the same order. This exposes order dependence. - Bisect: run the failing test with smaller and smaller groups of the earlier tests until you find the test that pollutes the state.
Usual causes:
- rows or cache keys left by other tests
- mock implementations that
clearAllMocksdidn't remove - module-level singletons or caches
process.envchanges that were not restored- fake timers left on
- in CI: a different time zone, locale, Node version, or a slower machine
Fix the leak at its source, not by reordering tests. For example, add cleanup in afterEach, or turn on restoreMocks in the Jest config.
- Reproduce the failure: alone, then in band, then in the full suite.
- Randomize the order with a seed, and bisect to find the polluting test.
- Typical leaks are data, mocks, singletons, env changes and fake timers.
- CI can differ in time zone, locale, Node version and speed.
- Fix the leak at its source.