Test Strategy: Deciding What Runs Where
As a lead, nobody asks you to write the tests. They ask you where tests should run and what's allowed to block a release. Good news — that's a smaller, calmer question than it sounds.
The idea, in one line
Fast, cheap checks run often. Slow, expensive checks run rarely. Speed decides where each test lives. Get that one rule right and the whole strategy falls into place.
Start with the test pyramid
The test pyramid is just the healthy shape of a test suite:
- Lots of unit tests at the bottom — tiny and fast, they check one piece in isolation.
- Fewer integration tests in the middle — they check that pieces work together.
- A thin layer of end-to-end (E2E) tests on top — they drive the whole app like a real user. Slow, and the first to go flaky.
The rule the shape teaches you: push every check as far down as it will go. Lower tests are faster and they point straight at what broke.
Now map it onto your pipeline
Here's the same idea as a plan for what runs at each stage of your build:
- On every pull request (PR): the cheap, reliable layer — lint, unit tests, contract tests. Keep it under ten minutes, or engineers stop reading the feedback.
- Nightly: the slow, flake-prone stuff — full E2E and the cross-browser matrix. Off the critical path, where it can take its time.
- At release: a quick smoke suite, plus a check that last night's full run was green.
What a quality gate really is
A quality gate is an explicit, machine-checked condition that code must pass before it moves forward. Not a gut feeling — a rule the pipeline enforces. Keep the rules few and visible: the build passes, coverage doesn't drop, no new critical security issues, smoke is green. Anything red stops the merge.
Advanced — why speed is the whole trade-off
It's tempting to run everything everywhere, just to be safe. But a slow PR check is worse than no check, because people learn to ignore it. Every placement decision is really the same question: is this fast and steady enough to gate a merge, or slow and flaky enough that it belongs in the nightly run? Say that reasoning out loud in an interview and you sound like a lead.
Grounded in Martin Fowler's 'The Practical Test Pyramid' and DORA (dora.dev) deployment-pipeline guidance