Chapter 2 · Practice 2 of 4
Rely mostly on fast tests, and keep slow ones few and focused
Why it matters
Not every test belongs on every commit. Fast, isolated tests (units and small integrations with fakes) give quick, precise answers. End-to-end tests through a browser or across services catch wiring problems but are slow and more likely to be flaky.
A healthy shape:
- Many unit and component tests, run on every push.
- Some integration tests against real dependencies in containers (a database, a queue).
- A few end-to-end tests covering the paths that make money or keep users safe: sign-in, checkout, payment.
DORA's continuous delivery guidance says developers should build and maintain most of the automated tests, rather than a separate team writing them after the fact. Tests written with the code stay in step with it.
To check, look at which suite fails most often for real bugs and which fails most often for no reason. Move investment toward the first.
Avoid
- Covering every edge case with browser tests
- A separate QA team as the only author of automated tests