test pollution: how one test breaks another

TL;DR

Test pollution is shared mutable state: databases, files, singletons, or time. Find the leak by running tests in different orders, then isolate with proper setup and teardown.

Error

(Not an error; a failure pattern. Symptom: test B fails only when run after test A.)

Steps

1. Confirm: run B alone (passes), then A then B (fails). Expected: pollution proven.
2. Identify the shared state: database rows, files on disk, in-memory singletons, mocked modules. Expected: the leak found.
3. Fix with isolation: transactions rolled back per test, temp directories per test, module registry reset. Expected: A cannot affect B.
4. Add teardown that verifies cleanliness: assert the DB is empty after each test in a sample. Expected: future pollution caught early.
5. Run the full file in random order several times. Expected: order independence proven.

When to use

• Pass-alone, fail-together patterns.
• After adding shared fixtures.

When not to use

• True timing flakes (no order dependence).
• Single-test failures.

Tool compatibility

• Any framework; random-order plugins per framework.

Variant phrasings

Test isolation failure

The general term; pollution is the cause.

Tests interfere with each other

The symptom; shared state is the mechanism.

Why it happens

Tests share a process, database, and filesystem by default. Anything one test mutates persists for the next unless cleaned.

Edge cases

• Module mocks in Jest leak between files unless reset; use resetMocks.
• Database sequences (auto-increment IDs) leak even with rollback; do not assert exact IDs.
• Time mocking leaks; always restore real timers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e0NVADs7LHwfh6L4n9LQLw