Skip to content
Back to Testing & QAAll lessons

Testing & QA

Flaky Tests (Why Tests Fail Intermittently)

The idea, in plain English

A flaky test is one that sometimes passes and sometimes fails without the code changing at all — like a car that starts fine most mornings but stalls on random cold days. Flaky tests are dangerous because they train your team to shrug and hit 'run again', and eventually a real bug gets ignored as 'just the flaky one'. They usually come from depending on something unstable: timing, random values, test order, or shared state that leaks between tests.

How it works

  1. 1Spot flakiness by running the same test several times — a truly good test gives the same answer every run.
  2. 2Hunt the unstable source: a real clock, a random number, a network call, or leftover data from an earlier test.
  3. 3Remove the dependence on luck. Wait for the real condition instead of a fixed sleep; seed randomness; reset shared state between tests.
  4. 4Re-run many times to confirm the result is now identical every single time.

When you'd use it

You deal with flakiness the moment a test fails intermittently in your pipeline. Fixing it matters even more than fixing a plainly-broken test, because a flaky suite quietly erodes everyone's trust in the tests entirely.

Common beginner mistakes

  • 'Fixing' flakiness by just retrying until it passes. That hides real bugs the test caught by chance instead of removing the instability.
  • Using a fixed sleep ('wait 1 second') to dodge timing issues. It's slow AND still flaky — wait for the actual condition to be true instead.

Try it — edit and run

Click the code to edit · press ⌘/Ctrl+↵ to run

Editable code. Tab and Shift+Tab indent. Press Escape, then Tab, to move focus out of the editor.

Expected output — hit Run to try it
Run 1: FAIL
Run 2: PASS
Run 3: FAIL
Same test, different results -> flaky!
Stable run: PASS

Not sure this is the right topic? See the learning paths → or where this leads →