Comprehensive testing strategy
Design a comprehensive testing strategy
The shape
| Level | Scope | Speed | Where it runs |
|---|---|---|---|
| Local | Developer's machine, pre-commit | Fastest | Before push |
| Unit | One component, dependencies faked | Fast | Every PR |
| Integration | Components together, real dependencies | Slower | PR or main |
| Load / performance | System under expected and peak traffic | Slowest | Scheduled or pre-release |
Choosing where a test belongs
The economics are simple: a defect caught locally costs a developer minutes, in a PR costs a build, in production costs an incident. Push tests as early as they can meaningfully run — but no earlier. A test that needs a real database is not a unit test just because you would like it to be fast.
Load testing is a different question
Unit and integration tests ask is it correct? Load tests ask does it still behave correctly under expected and peak traffic? They need a production-like environment and their results are statistical, so they usually run on a schedule or before a release rather than on every commit.
Flaky tests
A test that fails intermittently without a code change is worse than no test: it trains the team to re-run rather than investigate, and it hides real regressions. Track flakiness explicitly — pipeline health metrics include flaky test rate for exactly this reason — and quarantine or fix rather than retry blindly.
Primary sources