Test pollution happens when one test leaves behind data or a system state that affects another test. The failure appears unrelated, but the root cause is shared context leaking between tests.
This usually shows up when shared data is not cleaned up, system state is reused unintentionally, or resources remain locked or modified after a test finishes. As test suites grow, these hidden dependencies create failures that are hard to reproduce and even harder to trust.
For example, a user registration test creates abc@xyz.com but doesn’t delete it. Later, another test tries to register the same email and fails with “email already exists.” The second test looks broken, but the real issue is that the first test polluted the system. The failure depends on execution order, which makes it flaky and misleading.
The core problem is not the assertion, it’s isolation. Reliable tests must assume they run alone. That often means rolling back test transactions, generating unique test data, or running tests in disposable environments such as containers that are destroyed after each run.
One way teams uncover test pollution is by running tests in random order or executing individual tests in isolation. If results change based on order, hidden dependencies are already present.
This usually shows up when shared data is not cleaned up, system state is reused unintentionally, or resources remain locked or modified after a test finishes. As test suites grow, these hidden dependencies create failures that are hard to reproduce and even harder to trust.
For example, a user registration test creates abc@xyz.com but doesn’t delete it. Later, another test tries to register the same email and fails with “email already exists.” The second test looks broken, but the real issue is that the first test polluted the system. The failure depends on execution order, which makes it flaky and misleading.
The core problem is not the assertion, it’s isolation. Reliable tests must assume they run alone. That often means rolling back test transactions, generating unique test data, or running tests in disposable environments such as containers that are destroyed after each run.
One way teams uncover test pollution is by running tests in random order or executing individual tests in isolation. If results change based on order, hidden dependencies are already present.
