What Is Test Isolation?
Test isolation means each test runs independently, without depending on or affecting any other test.
A trustworthy test suite is one where each test stands alone. Test isolation is that property: a test sets up its own state, makes its assertions, and cleans up, so its result never depends on what ran before it. Without isolation, tests pass or fail based on order, which makes them flaky and impossible to parallelize.
What isolation requires
An isolated test does not read state left by another test, does not leave state behind, and does not share mutable globals. It owns its fixtures, resets anything it touches, and makes no assumption about execution order. Each test is a clean experiment.
How shared state breaks a suite
When tests share state, a global variable, a database row, a singleton, one test can leave the system in a state that makes another pass or fail. Such suites work in one order and break in another, and the failures look random. The bug is the coupling, not the individual tests.
A quick example
Resetting shared state before each test keeps one test from leaking into the next.
beforeEach(() => {
store.reset(); // clear state so tests do not bleed together
});Techniques for isolation
- Reset or rebuild state in setup and teardown.
- Give each test its own database transaction or schema.
- Avoid shared mutable globals and singletons.
- Stub the clock and randomness for determinism.
Isolation and parallel CI
Isolation is the prerequisite for running tests in parallel and across shards, because parallel tests must not collide over shared resources. It also prevents order-dependent flakiness. Running well-isolated suites on separate, clean runners reinforces that independence, which is part of how Latchkey keeps parallel test runs stable.
Key takeaways
- Test isolation means each test runs independently of the others.
- Shared state causes order-dependent, flaky failures.
- Isolation is what makes parallel and sharded CI runs possible.