If your team treats every unit test as sacred, you may already be paying a hidden tax. An overzealous approach to unit testing can quietly erode the very agility it's supposed to protect, making routine refactors slow, expensive, and politically painful.
The question isn't whether to test—it's which tests earn their place. The answer lives in the tension between two development mindsets: inside-out (white box) testing that scrutinizes every code unit, and outside-in (black box) testing that focuses on what the system produces. Think of it this way: inside-out is a Mercedes factory, where every component is engineered to fit perfectly. Outside-in is a junk car shed where you bolt together a Volkswagen and a motorcycle engine—just needs to drive fast.
Most teams default to inside-out because it's easier to measure and easier to argue about in a pull request. That's a local optimization with global consequences.
At a glance
- Unit tests are cheap to write but expensive to maintain, especially when they pin down internal code rather than user-facing behavior.
- Inside-out checks every internal unit; outside-in focuses on the result the system produces.
- Most real projects blend both, with the balance tipping toward behavior-driven, black-box coverage.
- Coverage rule of thumb: below 15% is too little, above 70% is generally fine, and 100% only makes sense for genuinely mission-critical systems.
How over-testing quietly erodes velocity
Agile and Scrum pushed teams toward more automated checks at the lowest level. Short cycles, fast feedback, continuous integration—all of it encouraged exhaustive unit testing.
For a while, that worked. Coverage climbed, bugs caught earlier, releases felt safer. Then codebases grew, teams scaled, and refactors became weekly events. Suddenly, every rename, every extract-method, every "small" cleanup meant rewriting dozens of tests that were really just snapshots of implementation details.
Unit tests, originally a safety net, started to behave like scaffolding bolted to the walls of the house.
The shift that changes everything
The conceptual shift is this: test the unit of functionality, not the unit of code. When your tests describe behavior a user or stakeholder cares about, they survive refactors. When they describe which private method called which mock, they don't.
In practical terms, treat parts of the system as black boxes. Write tests against public interfaces and observable outcomes. Let internal structure change freely underneath. This approach aligns well with domain-driven design, where system boundaries follow the language of the business rather than the shape of classes.
Coverage percentage shifts from gospel metric to tripwire. Use it to flag under-testing, not to grade engineers.
Who should care
| Role | Why it matters | What to do |
|---|---|---|
| Developers | Brittle tests turn refactors into politics; every "small" change triggers a rewrite | Write tests against behavior, not structure; delete tests that don't survive refactors |
| Tech leads and architects | Coverage dashboards look green while velocity flatlines | Prune in retros; treat tests like product code with a lifecycle |
| Product owners | Feature delivery slows because every change triggers a test maintenance storm | Question whether "tests written" belongs in your Definition of Done |
The exception: teams working on safety-critical software (aviation, medical, financial infrastructure) genuinely need exhaustive coverage. For them, 100% isn't a blog post recommendation—it's a regulatory requirement.
Our analysis
Inside-out gives you precision and confidence in internals; outside-in gives you speed, refactor-ability, and tests that age well. The problem is that teams chase inside-out because it's measurable. "This branch isn't covered" is an easy pull request comment. "These tests don't describe behavior worth keeping" is a judgment call most teams avoid.
The real agile win is treating tests like product code: prune them in retros, delete the ones that don't earn their keep, write new ones against behavior. Your sprint reviews should celebrate removing brittle tests, not just adding more.
Watch for the next shape of this debate: AI-assisted test generation, which tends to produce high-volume, low-judgment tests that look great on a coverage report and terrible in a refactor.
What to watch next
Stop chasing 100% coverage and start chasing coverage that survives a refactor. Audit your test suite this sprint: identify tests coupled to implementation, move energy toward behavior-driven checks. If your dashboard shows 70% coverage but your team still fears refactors, your tests are lying to you.
Key takeaways
- Treat tests as documentation of behavior, not proof of code structure.
- Use coverage as a tripwire for under-testing, not a scoreboard for engineers.
- Prune brittle tests in retros the same way you'd prune old requirements.
- Reserve 100% coverage ambitions for genuinely safety-critical systems.
Frequently asked questions
What is a healthy unit test coverage percentage?
Generally, anything below 15% is too little and above 70% is fine for most products. The exact number matters less than whether the tests still pass after a refactor.
How is "inside-out" testing different from "outside-in"?
Inside-out checks every internal code unit in detail, while outside-in focuses on the result the system produces, treating internals as a black box. Most projects blend the two.
Why can too many unit tests slow a team down?
Because tests tied to implementation details have to be rewritten every time the code is refactored, eating into sprint capacity and slowing delivery.
Is 100% test coverage ever worth pursuing?
Only in safety-critical domains where failure is unacceptable, such as aerospace or certain financial systems. For typical product work, the maintenance cost outweighs the benefit.
What's the link between unit testing and domain-driven design?
Testing units of functionality (the language of the business) rather than units of code tends to produce tests that stay valid as the codebase evolves, which is the same instinct behind domain-driven design.