State leakage happens when data, configuration, or system state from one action, test, or user session unintentionally affects another. Instead of starting from a clean and predictable state, behaviour is influenced by something left behind earlier.
This often shows up in tests that pass when run alone but fail when run together. For example, a test might rely on data created by a previous test, a user session might remain active longer than expected, or a cached value might change the outcome of a later action. The system appears inconsistent, even though the logic itself has not changed.
State leakage is risky because it hides real problems. Tests may pass for the wrong reasons, failures may be hard to reproduce, and bugs may only appear in certain orders or environments. This can lead to flaky tests and false confidence in system stability.
Reducing state leakage involves being clear about setup and cleanup, isolating tests where possible, and validating assumptions about system state. When state is controlled and predictable, behaviour becomes easier to reason about and failures become easier to trust.
This often shows up in tests that pass when run alone but fail when run together. For example, a test might rely on data created by a previous test, a user session might remain active longer than expected, or a cached value might change the outcome of a later action. The system appears inconsistent, even though the logic itself has not changed.
State leakage is risky because it hides real problems. Tests may pass for the wrong reasons, failures may be hard to reproduce, and bugs may only appear in certain orders or environments. This can lead to flaky tests and false confidence in system stability.
Reducing state leakage involves being clear about setup and cleanup, isolating tests where possible, and validating assumptions about system state. When state is controlled and predictable, behaviour becomes easier to reason about and failures become easier to trust.
