🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🕰️ धडा 11 — Flaky tests: भिंतीवरचे डुगडुगणारे घड्याळ

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · मागील: lesson-10-coverage-mutation · पुढील: lesson-12-ci-tdd

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि त्याशिवाय flaky tests: त्याच code वर कधी pass तर कधी fail होणाऱ्या tests. चार नेहमीची कारणे — वेळ, क्रम (shared state), randomness आणि वाट पाहणे — प्रत्येक कारण काहीही न बदलता test 1000 वेळा पुन्हा चालवून दाखवलेले, आणि मग बदलणारी गोष्ट पक्की करून सुधारलेले. flaky_time, fixed_time, order_runs, flaky_random, flaky_wait आणि rerun exam/lab.py मध्ये; is_late() exam/grades.py मध्ये; flaky() exam/demo.py मध्ये.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

परीक्षा हॉलमध्ये भिंतीवर एक घड्याळ आहे जे डुगडुगते. 🕰️ बहुतेक दिवस ते बरोबर असते. काही दिवस ते उडी मारते. लिहिणे कधी थांबवायचे हे ठरवण्यासाठी घड्याळाकडे पाहणाऱ्या विद्यार्थिनीचे कधी कधी चुकते — तिच्या उत्तरांमुळे नव्हे, तर घड्याळामुळे.

Flaky test अगदी तसाच असतो. Code बदलला नाही, पण test चा निकाल बदलला.

पर्यवेक्षण करणाऱ्या ऐश्वर्याला चार डुगडुगणारी घड्याळे सापडतात:

वेळ ⏰ — एक प्रश्न तपासतो "तासाभरात दिलेला गृहपाठ उशिरा नाही". तो दिवसभर pass होतो… आणि 23:00 नंतर fail होतो, जेव्हा "तासाभरात" म्हणजे उद्या असते.
क्रम 🔀 — तीन प्रश्न एकच वर्ग-यादी वापरतात. एका क्रमाने चालवले तर सगळे pass. इतर 5 पैकी कोणत्याही क्रमाने चालवले — काहीतरी fail होते.
Randomness 🎲 — एक प्रश्न 3 random गुण निवडतो आणि किमान एक pass अपेक्षित धरतो. सहसा खरे. कधी कधी तिन्ही 35 च्या खाली असतात.
वाट पाहणे ⏳ — एक प्रश्न report card छापायला सुरू करतो, 200 ms थांबतो, मग ते झाले का तपासतो. सहसा झालेले असते. कधी कधी printer हळू असतो.

ऐश्वर्याची पद्धत: प्रत्येक प्रश्न काहीही न बदलता 1000 वेळा चालवा. जो प्रश्न कधी pass आणि कधी fail होतो तो flaky. मग ती काय बदलते ते शोधते — आणि ते पक्के करते: ठरलेले घड्याळ, नवी यादी, ठरलेला seed, "पूर्ण होईपर्यंत वाट पाहा".

🗺️ आकृती

flowchart LR
    r["🔁 rerun 1000 times<br/>no code change"] --> t["⏰ time: 33 failed<br/>after 23:00"]
    r --> o["🔀 order: 5 of 6 orders fail"]
    r --> d["🎲 randomness: 36 failed"]
    r --> w["⏳ sleep 200 ms: 76 failed"]
    t --> f1["inject a fixed clock → 0"]
    o --> f2["fresh fixture per test → 0"]
    d --> f3["fixed seed or fixed data"]
    w --> f4["wait for done, not for time"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/testing/lesson-diagrams.html#l11

❓ काय

Flaky test — non-deterministic निकाल असलेली test: तोच code, तीच test, वेगळा निकाल. Google ने (2016) सांगितले की त्यांच्या सुमारे 1.5% test runs चा निकाल flaky होता आणि जवळपास 16% tests मध्ये काही ना काही flakiness दिसली.
वेळ — खरे घड्याळ वाचणाऱ्या tests, time zones, daylight-saving बदल, महिन्याचा किंवा वर्षाचा शेवट. उपाय: घड्याळ inject करा (now आत पाठवा) किंवा ते गोठवा.
क्रमावर अवलंबून असणे — दुसऱ्या test ने मागे सोडलेल्या state वर test अवलंबून असते (global list, database row, file, environment variable). उपाय: प्रत्येक test ला नवा fixture (धडा 04); random क्रमाने चालवून ते शोधा.
Randomness — seed नसलेला random data. उपाय: ठरलेला seed, ठरलेला data, किंवा सर्व inputs साठी खरी असणारी property (धडा 09) आणि seed छापलेला.
वाट पाहणे / concurrency — background काम संपले असेल या आशेने ठरावीक sleep, threads मधील races, आधीच वापरात असलेले ports. उपाय: उदार deadline ठेवून अटीची वाट पाहा, किंवा test मध्ये काम synchronous करा.
बाहेरच्या dependencies — network, shared staging server, दुसऱ्या team चा data. उपाय: बहुतेक tests साठी doubles (धडा 05) आणि contracts (धडा 07).
Retry-to-green — fail झालेल्या tests pass होईपर्यंत पुन्हा चालवणे. यामुळे flake लपतो; product मधला खरा अधूनमधून येणारा bug सुद्धा लपू शकतो. उपाय म्हणून नव्हे, तर ticket सह थोड्या काळाचे quarantine म्हणून वापरा.

🤔 का

कारण flaky suite लोकांना लाल रंगाकडे दुर्लक्ष करायला शिकवतो. एकदा "फक्त पुन्हा चालव" हे नेहमीचे उत्तर झाले, की खरे failure सुद्धा पुन्हा चालवले जाते — आणि ship होते. Flakiness वेळही वाया घालवते: धडा 08 च्या model मध्ये 200 e2e tests असलेला suite 87% runs मध्ये विनाकारण लाल होता. आणि flaky test हे कधी कधी flaky product चे एकमेव लक्षण असते — खरी race condition, खरा time-zone bug — म्हणून प्रत्येक flake कडे एकदा पाहायलाच हवे.

🔧 कसे (या repo मध्ये)

exam/lab.py मधील प्रत्येक flaky test बदलणारी गोष्ट parameter म्हणून घेते, म्हणजे ती पुन्हा चालवता येते. flaky_time(clock) due date साठी clock() बोलवते आणि पुन्हा hand-in वेळ अधिक एक तास यासाठी; exam/grades.py मधील is_late() म्हणते उशीर म्हणजे "due date नंतरच्या मध्यरात्री किंवा त्यानंतर". order_runs(fresh) module-level ROLL list वापरणाऱ्या तीन tests सर्व 6 क्रमांनी चालवते. flaky_random(rng) 3 गुण काढते; flaky_wait(rng) 200 ms sleep विरुद्ध एक job वेळ काढते (90% वेळा 50 ते 150 ms, 10% वेळा 150 ते 400 ms). rerun(test, n) test n वेळा चालवते आणि passes आणि fails मोजते. खरे घड्याळ आणि खरी randomness यांची भूमिका demo मध्ये seeded generators करतात, म्हणून त्याचे आकडे प्रत्येक run मध्ये तेच येतात.

🧪 करून पाहा

python3 exam/demo.py flaky
python3 - <<'EOF'
from datetime import datetime
from exam import lab
from exam.lab import Rng, rerun
for hour in (9, 22, 23):
    t = datetime(2026, 9, 1, hour, 30)
    print(f"flaky_time at {hour}:30 →", "pass" if lab.flaky_time(lambda: t) else "FAIL")
print("fixed_time at any hour →", "pass" if lab.fixed_time(None) else "FAIL")
print("same seed, 3 runs:", [lab.flaky_random(Rng(42)) for _ in range(3)])
print("fixed data, v3 of the test:", [any(lab.G.grade(s) != "F" for s in (20, 34, 50)) for _ in range(3)])
waits = Rng(13); p, f = rerun(lambda i: lab.flaky_wait(waits))
print(f"sleep 200 ms: passed {p}, failed {f}")
print("order: shared", lab.order_runs(False), "of 6 orders fail · fresh", lab.order_runs(True))
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

flaky हे छापते:

   time: due today, handed in within the hour    passed  967 · failed  33 → reads the real clock (fails after 23:00)
   randomness: 3 unseeded scores, one passes     passed  964 · failed  36 → unseeded random data
   waiting: sleep 200 ms, then check the job     passed  924 · failed  76 → a fixed sleep instead of waiting for done
   order: shared ROLL list, all 6 orders of 3 tests → 5 orders fail · fresh ROLL per test → 0 fail
── fixed: an injected clock → passed 1000, failed 0 · a seed → the same 3 scores every run · wait for 'done', not for time

तुमचा snippet हे छापतो:

flaky_time at 9:30 → pass
flaky_time at 22:30 → pass
flaky_time at 23:30 → FAIL
fixed_time at any hour → pass
same seed, 3 runs: [True, True, True]
fixed data, v3 of the test: [True, True, True]
sleep 200 ms: passed 924, failed 76
order: shared 5 of 6 orders fail · fresh 0

🏁 तुम्ही आत्ताच काय सिद्ध केले

चारपैकी प्रत्येक test पहिल्याच प्रयत्नात pass झाली असती — failure rates प्रत्येक run मागे 3–8% होते, किंवा 6 पैकी असे 5 क्रम जे runner आज योगायोगाने वापरत नाही. फक्त काहीही न बदलता पुन्हा चालवल्याने ते उघड झाले. Demo मध्ये time test सुमारे 30 पैकी 1 run मध्ये fail झाली, "23:00 नंतर" वरून अपेक्षित असलेल्या 24 पैकी 1 च्या जवळ. बदलणारी गोष्ट एकदा parameter झाली — घड्याळ, यादी, seed — की test हवी तेव्हा 23:30 ला पुन्हा चालवता आली, आणि सुधारता आली. Seeded random test कडे लक्ष द्या: seed तिला पुन्हा-पुन्हा सारखी करतो, बरोबर नाही; प्रामाणिक उपाय होता मुद्दाम निवडलेला data (20, 34, 50).

⚠️ नेहमीच्या चुका

time.sleep(0.2) आणि आशा — त्याऐवजी अटीची वाट पाहा
code मध्ये खोलवर datetime.now(), जिथे कोणतीही test ते नियंत्रित करू शकत नाही
"fail झालेल्या tests 3 वेळा पुन्हा चालवा" हे कायमचे setting म्हणून
flaky test चा assert delete करून तो "सुधारणे"
"ही फक्त test आहे" म्हणून product ठीक आहे असे गृहीत धरणे — कधी कधी race खरी असते

🏭 प्रत्यक्ष वापरात

खऱ्या project मध्ये — freezegun (किंवा time-machine) ने वेळ गोठवा, pytest-randomly ने क्रम random करा, आणि संशयित test pytest-repeat ने पुन्हा पुन्हा चालवा:

from freezegun import freeze_time
from datetime import datetime, timedelta
from exam.grades import is_late

@freeze_time("2026-09-01 23:30:00")
def test_late_night_hand_in():
    now = datetime.now()                                      # frozen
    assert is_late(now + timedelta(hours=1), now.date())      # the rule, stated for 23:30

pip install pytest-randomly pytest-repeat pytest-rerunfailures
pytest                                     # with pytest-randomly installed: shuffled order, "Using --randomly-seed=…"
pytest --randomly-seed=1234                # replay the exact order that failed
pytest --count=200 -x tests/test_report.py # pytest-repeat: run one file 200 times, stop at the first failure

Quarantine मधल्या माहीत असलेल्या flaky test साठी, pytest-rerunfailures फक्त तुम्ही mark केलेलेच पुन्हा चालवते — त्या एका test वर @pytest.mark.flaky(reruns=2) — आणि ते mark काढण्यासाठी एक ticket.

कालावधीची नव्हे, अटीची वाट पाहा — Playwright चे expect(...).to_have_text(...) timeout पर्यंत पुन्हा प्रयत्न करते; साध्या code मध्ये, deadline ठेवून poll करा:

import time
def wait_until(cond, timeout=5.0, step=0.05):
    end = time.monotonic() + timeout
    while time.monotonic() < end:
        if cond(): return True
        time.sleep(step)
    raise TimeoutError("condition not met")

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: flaky tests bugs सारखे track करा — मालकांसह यादी. Flaky test ला quarantine करा (ती चालते, पण merges अडवत नाही) — महिने नव्हे, दिवस. प्रत्येक failure चा seed, क्रम आणि वेळ नोंदवा, म्हणजे ते पुन्हा चालवता येईल.

⏭️ पुढे

सगळे तुकडे जागेवर आहेत. शेवटचा धडा: tests कधी चालतात — TDD त्या आधी लिहिते, आणि CI प्रत्येक बदलावर योग्य त्या चालवते. आणि परीक्षा हॉलचे संपूर्ण चित्र.

git checkout lesson-12-ci-tdd

🕰️ Lesson 11 — Flaky tests: the wobbly clock on the wall

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-coverage-mutation · Next: lesson-12-ci-tdd

📦 What's in this branch

Lessons 01–10, plus flaky tests: tests that pass and fail on the same code. Four common causes — time, order (shared state), randomness and waiting — each shown by rerunning a test 1000 times with nothing changed, then fixed by pinning down the thing that varies. flaky_time, fixed_time, order_runs, flaky_random, flaky_wait and rerun in exam/lab.py; is_late() in exam/grades.py; flaky() in exam/demo.py.

🧒 Explain like I'm 5

The exam hall has a clock on the wall that wobbles. 🕰️ Most days it is right. Some days it jumps. A pupil who looks at the clock to decide when to stop writing sometimes gets it wrong — not because of her answers, but because of the clock.

A flaky test is like that. The code did not change, but the test result did.

Aishwarya, who invigilates, finds four wobbly clocks:

Time ⏰ — a question checks "homework handed in within the hour is not late". It passes all day… and fails after 23:00, when "within the hour" is tomorrow.
Order 🔀 — three questions share one class list. Run them in one order, all pass. Run them in any of the other 5 orders — something fails.
Randomness 🎲 — a question picks 3 random scores and expects at least one pass. Usually true. Sometimes all three are below 35.
Waiting ⏳ — a question starts printing a report card, waits 200 ms, then checks it is done. Usually it is. Sometimes the printer is slow.

Aishwarya's method: run each question 1000 times with nothing changed. A question that both passes and fails is flaky. Then she finds what varies — and nails it down: a fixed clock, a fresh list, a fixed seed, "wait until done".

🗺️ Diagram

flowchart LR
    r["🔁 rerun 1000 times<br/>no code change"] --> t["⏰ time: 33 failed<br/>after 23:00"]
    r --> o["🔀 order: 5 of 6 orders fail"]
    r --> d["🎲 randomness: 36 failed"]
    r --> w["⏳ sleep 200 ms: 76 failed"]
    t --> f1["inject a fixed clock → 0"]
    o --> f2["fresh fixture per test → 0"]
    d --> f3["fixed seed or fixed data"]
    w --> f4["wait for done, not for time"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/testing/lesson-diagrams.html#l11

❓ What

Flaky test — a test with a non-deterministic result: same code, same test, different outcome. Google reported (2016) that about 1.5% of its test runs gave a flaky result and that almost 16% of its tests showed some flakiness.
Time — tests that read the real clock, time zones, daylight-saving changes, the end of a month or year. Fix: inject the clock (pass now in) or freeze it.
Order dependence — a test relies on state another test left behind (a global list, a database row, a file, an environment variable). Fix: a fresh fixture per test (lesson 04); find it by running in random order.
Randomness — unseeded random data. Fix: a fixed seed, fixed data, or a property that holds for all inputs (lesson 09) with the seed printed.
Waiting / concurrency — a fixed sleep hoping background work has finished, races between threads, ports already in use. Fix: wait for the condition with a generous deadline, or make the work synchronous in the test.
External dependencies — the network, a shared staging server, another team's data. Fix: doubles (lesson 05) and contracts (lesson 07) for most tests.
Retry-to-green — rerunning failed tests until they pass. It hides the flake; it can also hide a real intermittent bug in the product. Use it as a short quarantine, with a ticket, not as the fix.

🤔 Why

Because a flaky suite teaches people to ignore red. Once "just rerun it" is the normal answer, a real failure gets rerun too — and ships. Flakiness also wastes time: in lesson 08's model a suite with 200 e2e tests was red for no reason in 87% of runs. And a flaky test is sometimes the only sign of a flaky product — a real race condition, a real time-zone bug — so each one deserves a look.

🔧 How (in this repo)

Each flaky test in exam/lab.py takes the thing that varies as a parameter, so it can be replayed. flaky_time(clock) calls clock() for the due date and again for the hand-in time plus one hour; is_late() in exam/grades.py says late means "at or after midnight after the due date". order_runs(fresh) runs three tests that share the module-level ROLL list in all 6 orders. flaky_random(rng) draws 3 scores; flaky_wait(rng) draws a job time (90% between 50 and 150 ms, 10% between 150 and 400 ms) against a 200 ms sleep. rerun(test, n) runs a test n times and counts passes and fails. The demo uses seeded generators to play the part of the real clock and real randomness, so its counts are the same every run.

🧪 Try it

python3 exam/demo.py flaky
python3 - <<'EOF'
from datetime import datetime
from exam import lab
from exam.lab import Rng, rerun
for hour in (9, 22, 23):
    t = datetime(2026, 9, 1, hour, 30)
    print(f"flaky_time at {hour}:30 →", "pass" if lab.flaky_time(lambda: t) else "FAIL")
print("fixed_time at any hour →", "pass" if lab.fixed_time(None) else "FAIL")
print("same seed, 3 runs:", [lab.flaky_random(Rng(42)) for _ in range(3)])
print("fixed data, v3 of the test:", [any(lab.G.grade(s) != "F" for s in (20, 34, 50)) for _ in range(3)])
waits = Rng(13); p, f = rerun(lambda i: lab.flaky_wait(waits))
print(f"sleep 200 ms: passed {p}, failed {f}")
print("order: shared", lab.order_runs(False), "of 6 orders fail · fresh", lab.order_runs(True))
EOF

✅ Verify — what you should see

flaky prints:

   time: due today, handed in within the hour    passed  967 · failed  33 → reads the real clock (fails after 23:00)
   randomness: 3 unseeded scores, one passes     passed  964 · failed  36 → unseeded random data
   waiting: sleep 200 ms, then check the job     passed  924 · failed  76 → a fixed sleep instead of waiting for done
   order: shared ROLL list, all 6 orders of 3 tests → 5 orders fail · fresh ROLL per test → 0 fail
── fixed: an injected clock → passed 1000, failed 0 · a seed → the same 3 scores every run · wait for 'done', not for time

Your snippet prints:

flaky_time at 9:30 → pass
flaky_time at 22:30 → pass
flaky_time at 23:30 → FAIL
fixed_time at any hour → pass
same seed, 3 runs: [True, True, True]
fixed data, v3 of the test: [True, True, True]
sleep 200 ms: passed 924, failed 76
order: shared 5 of 6 orders fail · fresh 0

🏁 What you just proved

Every one of the four tests would pass on a first try — the failure rates were 3–8% per run, or 5 orders out of 6 that a runner happens not to use today. Only rerunning with nothing changed revealed them. The time test failed about 1 run in 30 in the demo, close to the 1 in 24 you expect from "after 23:00". Once the varying thing was a parameter — a clock, a list, a seed — the test could be replayed at 23:30 on demand, and fixed. Note the seeded random test: a seed makes it repeatable, not right; the honest fix was data chosen on purpose (20, 34, 50).

⚠️ Common mistakes

time.sleep(0.2) and hope — wait for the condition instead
datetime.now() deep inside the code, where no test can control it
"rerun failed tests 3 times" as a permanent setting
fixing a flaky test by deleting its assert
assuming the product is fine because "it is only the test" — sometimes the race is real

🏭 In production

On a real project — freeze time with freezegun (or time-machine), randomise order with pytest-randomly, and repeat a suspect test with pytest-repeat:

from freezegun import freeze_time
from datetime import datetime, timedelta
from exam.grades import is_late

@freeze_time("2026-09-01 23:30:00")
def test_late_night_hand_in():
    now = datetime.now()                                      # frozen
    assert is_late(now + timedelta(hours=1), now.date())      # the rule, stated for 23:30

pip install pytest-randomly pytest-repeat pytest-rerunfailures
pytest                                     # with pytest-randomly installed: shuffled order, "Using --randomly-seed=…"
pytest --randomly-seed=1234                # replay the exact order that failed
pytest --count=200 -x tests/test_report.py # pytest-repeat: run one file 200 times, stop at the first failure

For a known-flaky test in quarantine, pytest-rerunfailures retries only what you mark — @pytest.mark.flaky(reruns=2) on that one test — with a ticket to remove the mark.

Wait for a condition, not a duration — Playwright's expect(...).to_have_text(...) retries until a timeout; in plain code, poll with a deadline:

import time
def wait_until(cond, timeout=5.0, step=0.05):
    end = time.monotonic() + timeout
    while time.monotonic() < end:
        if cond(): return True
        time.sleep(step)
    raise TimeoutError("condition not met")

🏭 Why this matters in production: track flaky tests like bugs — a list with owners. Quarantine a flaky test (it still runs, but does not block merges) for days, not months. Record the seed, the order and the time of every failure, so it can be replayed.

⏭️ Next

All the pieces are in place. Last lesson: when tests run — TDD writes them first, and CI runs the right ones on every change. And the whole picture of the exam hall.

git checkout lesson-12-ci-tdd

← Previouscoverage mutation Next →ci tdd

This page is the lesson's README from the lesson-11-flaky-tests branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.