Independent

Tests should not rely on each other

“Tests should not depend on each other. One test should not set up the conditions for the next test.” – Robert C. Martin

Part of the F.I.R.S.T. principles.

When to use

Always.

Why it matters

Debugging: If Test B fails only when Test A runs first, it’s a nightmare to debug.
Parallelization: You can run tests in random order or in parallel processes if they are independent.

Signs of Violation

Global variables persisting between tests.
Database rows created in Test A being read in Test B.
“Test Suite must run in order” warnings.

Explanation

Problem

Cascading failures. If Test 1 fails and leaves garbage data, Tests 2-100 might fail too, masking the real issue.

Solution

Setup and Teardown. Reset the state before/after every single test.

Real world analogy

Bowling. Every frame starts with 10 pins standing up. If you didn’t clear the fallen pins from the previous player, the game would be unfair and confusing.

Pros and Cons

Pros	Cons
Robustness Order independence	Setup/Teardown overhead

Comparison

Shared Fixtures: Can be used for read-only data, but mutable state must be reset.