VocalHyre
Sign up

CI/CD · Ship safely, repeatedly

What is the test pyramid and is it still useful?

Mediumtest pyramidtestingstrategyUpdated Oct 2026
Quiz this track

Short answer

The test pyramid says to have many fast unit tests, fewer integration tests and a small number of end-to-end tests. It is a useful default about feedback cost, not a rule that forbids other test mixes.

The pyramid encodes a trade-off: lower-level tests are fast and precise but do not prove the system works together, while end-to-end tests are realistic but slow and brittle. The right mix depends on where risk lives.

  • Unit tests: milliseconds, isolate logic, cheap to run on every commit
  • Integration tests: seconds, verify real boundaries such as SQL, HTTP and serialization
  • Contract tests: check that services agree on requests and responses without a full environment
  • End-to-end tests: minutes, prove a critical journey through the deployed system
  • Exploratory and manual testing still matter for usability and novel failure modes
text
unit        many, fast, isolated
integration fewer, real boundaries
e2e         few, critical user journeys
Some teams use a testing trophy that gives more weight to integration tests. That is reasonable when the main risk is wiring rather than pure logic. The principle is still to optimize for confidence per unit of runtime.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1When would you write more integration tests than unit tests?
  2. 2How do contract tests fit into the pyramid?
  3. 3What is the ice-cream cone anti-pattern?
  4. 4How do you decide which user journeys deserve end-to-end coverage?

Say it in the interview

The pyramid is a heuristic about cost and confidence: many fast unit tests, fewer integration tests, and a small set of end-to-end tests for critical journeys. I do not apply it mechanically. If the risk is in service contracts or database behaviour, I invest more in integration and contract tests. The goal is the most confidence for the least runtime and flakiness.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

EasyWhat tests should run in CI?HardHow do you speed up a slow pipeline?EasyWhat does continuous integration actually require?

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.

Start a free CI/CD interviewBrowse all questions