Question 5
Balancing speed vs confidence
How do you balance the need for fast iteration with the need for strong test coverage and confidence in releases?
Follow-ups
- What do you gate on before App Store submission?
Answer outline
Aim for the right tests at the right level rather than the highest coverage number. Coverage tells you which lines ran. It says nothing about whether a release is safe.
Unit tests are cheap and fast, so run them on every change. Integration and UI tests are slower, so reserve them for critical flows and run them less often. That keeps iteration quick without giving up confidence where it counts.
Prioritize around risk. High-value business flows deserve thorough coverage, and trivial glue code doesn't. A suite that engineers trust and actually run beats one with impressive numbers that nobody waits for.
Principles
- Treat the coverage number as a byproduct of good tests, never as the goal.
- Run unit tests constantly because they're cheap, and save the slower tests for critical paths.
- Give high-risk flows such as sign-in and purchase deep coverage, and let glue code get by with less.
- A slow or unreliable suite gets skipped, so trust and speed matter as much as coverage.
Follow-up angles
- Before App Store submission, gate on a green unit and integration suite in CI. Then run the UI tests for the critical journeys, such as onboarding and purchase, against the release build.
