Test isolation
Test isolation is the property that each test runs independently — no shared state, no execution-order dependency, no side effects bleeding to the next test. Isolated tests can run in any order or in parallel, fail individually with clear cause, and don't produce cascading failures from a single root cause.
Test isolation is the foundation of a fast, reliable test suite. Common isolation failures: shared mutable state (a fixture modified by one test affects the next), incomplete teardown (database rows from one test affect another), order-dependence (test B passes when run after test A but fails alone), and global mocks (a mock installed in one test leaks to others). The remediation patterns are mechanical: per-test setup/teardown, transactional rollback for database tests, mock cleanup in afterEach, parallel execution to expose hidden order-dependency. The investment pays back permanently — isolated suites stay isolated; mixed suites tend toward more entanglement.
Related terms
- Test fixture
A test fixture is the prepared state required to run a test — input data, mocked dependencies, configured environment, seeded database rows.
- Flaky test
A flaky test is one that sometimes passes and sometimes fails without any code change — typically caused by timing dependencies, shared state, network/external-system reliance, or race conditions.
- Test data management
Test data management is the discipline of producing, maintaining, and isolating the data used in tests — fixtures, factories, seeded databases, anonymised production snapshots.