When Tests Keep Passing, but Design Stops Moving

Source: Dev.to

The Stalling Design Problem

There’s a moment I keep encountering when practicing TDD: tests pass, coverage improves, and refactoring feels safe. Yet, at some point, the design just stops moving. It’s not because the system is finished or the problem solved, but because the tests no longer challenge anything. They keep confirming decisions that already feel locked in.

The stall is subtle—nothing is obviously wrong, but learning has slowed to a crawl. Every new test feels inevitable, and the system still changes, but only within boundaries set long ago.

How Tests Shift Roles

I don’t think this happens because we write tests incorrectly. It happens when tests quietly shift roles. At first, tests are exploratory, but over time many become something else. When that happens, a green test no longer reduces doubt, even though the feedback loop is still running.

Looking back, what surprised me wasn’t that the design stalled, but how early some assumptions had solidified—often without being explicitly designed:

• class boundaries
• data shapes
• integration points
• what tests bothered to assert—and what they didn’t

Once those assumptions are encoded deeply enough, design work hasn’t truly stopped, but it no longer feels necessary.

Experiments to Re‑ignite Design

That realization pushed me toward some uncomfortable experiments:

• Writing tests that cut end‑to‑end much earlier than felt reasonable.
• Thinking less in terms of features and more about what must never break, no matter how the system evolves.
• Paying attention to what actually changed for me.

Often, the shift wasn’t about confidence in correctness; it was the moment I no longer felt the need to question the design. This isn’t an argument for more tests. What mattered wasn’t where the test lived, but what kind of pressure it applied. Some tests only verify that parts fit together; those collisions are uncomfortable, but they’re also where design tends to move again.

What This Is Not

This is not an argument that tests should replace design work. It’s an observation that some assumptions look stable on paper, and in those cases certain tests don’t substitute for design.

Implications in the Age of AI‑Assisted Coding

Recently, the question has felt more urgent. With AI‑assisted coding, it’s trivial to generate plausible implementations, passing tests, and convincing refactors. Green becomes cheap, making it even easier for assumptions to settle unnoticed. If tests only confirm structure, the real question becomes:

Who is still responsible for noticing when design stops moving?

Reframing the Relationship Between Tests and Design

I’m not proposing a new methodology; I’m offering a reframing. Design isn’t a phase that precedes tests. In their most useful form, tests are instruments of doubt. When tests stop serving that purpose, it’s a signal that something is amiss, and the work is to find a way forward.

A green test doesn’t mean “this part is correct.” Sometimes it just means that an assumption has quietly stopped being questioned. When design stops moving, that’s the part I’m still trying to understand.