The Test That Passes on Monday but Fails on Friday

🧠 Daily Dev Motivation — July 29, 2026

The Test That Passes on Monday but Fails on Friday

It's Monday. You merge your PR, CI turns green — 347 tests, zero failures. You genuinely smiled at your screen.

Friday afternoon. Someone else's PR breaks CI. Same 347 tests. Test #128 fails: assert order.total == 49.99 got 49.989999999999995. Floating point. You run it locally: pass. Full suite: pass. CI again: fail. Different line this time.

The team chat lights up. "Is the test flaky?" "Must be CI being weird." Someone labels it needs-investigation. Three weeks later, that label is still there.

Here's the truth: Flaky tests aren't testing logic — they're testing conditions. A deterministic test says "given X, return Y." A flaky test says "given X, return Y — assuming the clock is right, the database is warm, the network isn't slow, the previous test left the right state, and the garbage collector feels generous."

The mindset shift:

• Flaky tests are feature requests for determinism — don't add time.sleep() and move on, that's bribing the test


• Seed your randomness — fixed seeds, fixed fixtures, fixed clocks


• Test isolation is not optional — if test A needs test B, they're one test split across two files


• Quarantine the unfixable — put genuinely non-deterministic tests in their own suite, don't let them gate CI


• Fix the flakiness before the "bug" — a flaky test can't tell you signal from noise

"A flaky test is the system's way of saying 'I have a secret dependency you haven't named yet.' Don't silence it — introduce yourself."