4 ms·
Ask HN: When tests keep passing but design stops moving
I’ve been practicing TDD for a while, and I keep running into the same uncomfortable moment.
Tests pass.
Coverage improves.
Refactoring feels safe.
But at some point, the design just… stops moving.
Not because the system is “done,”
but because the tests no longer seem to challenge anything.
They mostly confirm decisions that already feel locked in.
I don’t have a clean explanation for this.
What I started suspecting is that some assumptions quietly become fixed
long before we realize they have.
That pushed me toward a few uncomfortable experiments.
For example, I started writing tests that cut end-to-end much earlier than felt reasonable,
and tried to think less in terms of features
and more in terms of “what must never break.”
I also started paying attention to what actually changes for me
when a test turns green —
often it’s not confidence in correctness,
but whether I still feel the need to question a particular assumption.
I wrote up these observations here:
https://github.com/felix-asher/the-essence-of-tdd
I’m not proposing a new methodology or a replacement for how TDD is usually taught.
I’m mostly curious whether others have hit the same stall point —
where tests keep passing, but design learning seems to plateau.
If you’ve seen this,
what helped you notice it — or get unstuck?
- JohnFen 9mo agoI'm not sure I understand what your dev process actually is. I get the impression that you're using the tests you write as a substitute for design work. Is that correct? If so, I think that's the root of the trouble. Do your design work as a separate step that precedes writing test cases.
- felixasher 9mo agoThanks — that’s a fair question, and probably on me for not being clear. I’m not trying to replace design work with tests. What I’m experimenting with is using certain tests (especially integration-level ones) as a way to surface and challenge assumptions that feel stable on paper. In other words, the tests aren’t the design, but they’re sometimes the fastest way I’ve found to discover where my “separate design step” was incomplete or misleading. Happy to clarify more if helpful.
- aydin212 9mo agoThat stall happens when tests stop being a design tool and become just a correctness check. Switching the prompt from "Does this work?" to "What would break if this core assumption changed?" has helped me break through it.
- felixasher 9mo agoYes — that framing resonates a lot. That shift from “does this work?” to “what breaks if this assumption is wrong?” is very close to what I’ve been circling around. For me, the stall seems to happen when green tests stop reducing doubt and start just confirming structure. Integration-level tests sometimes help me reintroduce that pressure. Really appreciate you articulating it so clearly.
- veeduzyl 9mo agoI’m experimenting with a cold guardrail for refactor risk. If it blocks you (or fails to), feedback is here: GitHub Discussion: “Feedback: tell me when it interrupts you”
- felixasher 9mo ago“Cold guardrail” resonates. I’ve been running guardrails only at slice boundaries as well. Deciding when interruption is justified has been surprisingly non-trivial.