A good testing strategy answers one question: can we change this code with confidence? Coverage percentage does not answer it. A suite can sit at ninety percent line coverage and still collapse the moment someone renames an internal method, because every test is welded to implementation detail. Meanwhile a leaner suite that exercises real behavior through real entry points survives an aggressive refactor untouched — and enabling refactoring is exactly what tests are for.
The distinction matters more as a codebase ages. Early on, almost any test helps. At scale, the wrong tests actively slow you down: they fail for reasons unrelated to correctness, they get skipped or deleted under deadline pressure, and the team quietly stops trusting the suite. At that point you are paying the full maintenance cost of testing without receiving the confidence it was supposed to buy.
Test Behavior, Not Structure
The unit under test should be a unit of behavior, not a class or a file. Three rules get you most of the way:
- ▸Enter through public interfaces: call the HTTP handler, the exported function, or the rendered component the way a real consumer would; if you must reach into private state to assert, either the design or the test is wrong.
- ▸Use real collaborators by default: stub the network, the clock, and third-party APIs — the genuinely nondeterministic edges — but let your own domain objects talk to each other; heavy mocking of internal seams is how one rename breaks fifty tests at once.
- ▸Assert observable outcomes: response bodies, emitted events, rows written — never that method X was called with argument Y, which is an implementation detail wearing a test's clothing.
Rebalance Toward Integration
Mike Cohn's test pyramid preached many unit tests and few integration tests, back when integration tests meant slow, shared, brittle environments. Kent C. Dodds' testing trophy reflects the current reality: with Testcontainers spinning up a real PostgreSQL in seconds, Testing Library rendering components against a real DOM, and Playwright driving a real browser reliably, integration tests are no longer the expensive tier. They catch the bugs that actually matter — wiring, serialization, SQL, configuration — at a cost that unit tests of glue code never justify.
Keep pure unit tests where they shine: algorithms, parsers, pricing rules, date math — code with high logical density and no I/O. Keep end-to-end tests to a thin smoke layer covering the money paths: signup, login, checkout, the flows where a failure is an incident.
Contracts at Service Boundaries
The bugs that in-repo integration tests cannot catch live between services. Consumer-driven contract testing with Pact, or schema-first validation against an OpenAPI or protobuf definition, lets a consumer publish the exact requests and expectations it relies on, and blocks a provider deploy that would break them — without either team standing up a full staging environment. If a shared staging cluster is currently the only place cross-service breakage gets discovered, contracts are the highest-leverage improvement available to you.
Run Flakiness Like an Ops Problem
A test that fails five percent of the time does not need courage or blanket retries; it needs process:
1. Track pass rate per test across recent CI runs; the data already exists in your CI system. 2. Auto-quarantine tests that fall below your reliability threshold — they keep running but stop blocking merges. 3. Open an owned ticket for every quarantined test, routed by CODEOWNERS, with a fixed deadline. 4. Fix it or delete it when the deadline passes; a permanently quarantined test is just a slower way of having no test. 5. Review the flake trend monthly — a rising curve usually points at shared state, time dependence, or port collisions in your harness, not at bad luck.
Retry-on-failure settings deserve particular suspicion: they convert visible flakiness into invisible slowness and let real race conditions ship to production behind a green checkmark.
The payoff of getting this right is not a dashboard number, it is speed. A trustworthy suite is what lets a team merge a dependency upgrade on a Friday, refactor a payment module without a war room, and onboard a new engineer who can change unfamiliar code and know within minutes whether it still works. Confidence to change software quickly is the entire economic point of testing — and it is worth designing for as deliberately as you design the software itself.