This cheatsheet gives you a fast decision framework for API testing so you can choose the right layer, balance speed versus confidence, and ship reliable changes without over-investing in slow end-to-end tests for problems better solved earlier in the stack and closer to the actual source of failure.
Test Layer Ratios
Use this as a starting point:
- Unit tests: 60%
- Integration tests: 25%
- Contract tests: 10%
- End-to-end tests: 5%
Decision Rules
- If logic is pure and deterministic, write a unit test.
- If two modules collaborate with side effects, write an integration test.
- If your service has public HTTP APIs, add contract tests for critical paths.
- Use end-to-end tests only for user journeys and release confidence.
Pull Request Quality Gate
- Does every bug fix include at least one regression test?
- Is the test added at the lowest useful layer?
- Are slow tests marked and isolated in CI?
- Can failures be reproduced locally in under 5 minutes?
Flaky Test Triage
When a test fails intermittently, ask:
- Is time involved (timeouts, clocks, TTL)?
- Is environment shared (state leakage, parallelism)?
- Is network involved (retry policy, unstable dependency)?
If the test is still flaky after 2 attempts, quarantine it and create a follow-up ticket.