Talk it through with Aurelius
Library›Aurelius›The problem
Aurelius · Work & Leadership
Knowledge + Guidance

Why do my tests pass, but bugs still get through?

You can write a test. You know the syntax, the assertions, the tools. That was never in question. The real problem is who you are when you sit down to write one. You built the thing. Part of you wants it to pass — so you test the path you already know works, and you call that coverage. A bug does not live on the path you know. It lives in the place you did not think to look. No one finds that place by being kind to their own work. You find it by becoming, on purpose, the code's enemy for twenty minutes.

◆ How this problem reads on the two dials
GuidanceKnowledge
More coaching
Some to learn
1:1 with AureliusWith others (a Pod)
Mostly you & the coach
A little with peers
The missing piece is a habit of mind, not a missing technique, so most of the work is practiced reframing rather than instruction.
How the two dials adapt to you →
What’s really going on

You test like the builder, not the breaker. You confirm what you already believe about your own code instead of hunting for where it lies to you. Stop asking 'does this work.' Ask 'how does this fail.' That single change in posture is the whole fix.

🔒 What you’ll build togetherUnlock by starting
A moveBefore writing a single test, list five ways this code could fail — not features it should have, ways it could break.
A moveFor every input you expect, name one it did not expect: empty, negative, enormous, malformed, missing entirely.
A moveAsk what happens if the thing this code depends on lies to it, answers slowly, or does not answer at all.
A moveLook at the first test you wrote. If it only proves the happy path works, set it aside and write the one you were avoiding.
A moveAfter any bug escapes, write the test that would have caught it — then ask what else that same blind spot is hiding.

What changes unlock by starting

  • You stop writing tests that merely confirm what you already believed about your own code.
  • You build a habit of listing failure modes before you code, not after a bug finds you first.
  • Your suite starts catching real bugs before release instead of just documenting intended behavior.
  • You can turn adversarial on command, without someone else having to point out what you missed.

Related problems

One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.