Flaky test
A test that passes and fails at random on the exact same code, usually because of timing, shared state, or the real-world clock.
See it
What it is
A flaky test gives different verdicts on identical code. Same commit, green at 10am, red at 10:04. The test is not haunted: something outside the assertion is varying. The usual suspects are timing (sleeping for a fixed 500ms instead of waiting for a condition), shared state (two tests fighting over the same database row or the same localStorage key), test order (test B only passes because test A ran first), and the outside world (real network calls, the system clock, time zones, Date.now(), random seeds, animations that have not finished).
Fixes follow the cause. Wait for conditions, not durations: Playwright's auto-waiting locators and Testing Library's findBy queries exist for exactly this. Freeze time with fake timers. Give every test its own data, unique per run, and reset state in teardown. Stub the network at the boundary so a slow third party cannot vote on your build.
The real gotcha is the cure that makes it worse: blanket retries. Auto-retrying until green hides a race condition that is also a race condition in production, and it trains the team to reflex-rerun red builds. Better: quarantine the flake so it stops blocking merges, log it as a bug with an owner, and track the flake rate. A suite people have learned to ignore is worth roughly nothing.
Ask AI for it
Diagnose and fix this flaky test. Identify the source of nondeterminism (fixed sleeps, shared state between tests, test-order dependence, real network calls, Date.now or random values, unfinished animations), then rewrite it to be deterministic: replace fixed waits with condition-based waiting (findBy / await expect(locator).toBeVisible), use fake timers for anything time-based, generate unique test data per run, and reset all shared state in beforeEach/afterEach. Do not add a retry to make it pass.