CodePark/ questions / Isolation, parallelism & flaky tests
START PRACTICINGPRACTICE
Backend question · Backend testing › Isolation, parallelism & flaky tests

A test passes when run on its own but fails when the whole suite runs, or only in CI. How do you track down the cause?

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 --randomize to shuffle the test order within files. Use --seed to 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 clearAllMocks didn't remove
  • module-level singletons or caches
  • process.env changes 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.