Explain the Test Pyramid and how it guides testing strategy
Your grasp of test cost, speed, and brittleness by layer.
Favor fast unit tests, a middle service layer, and few UI tests as second defense.
Treating it as a fixed ratio or saying all end-to-end tests need a.
What's really being asked
This question probes whether you treat testing as an economic portfolio decision rather than a checkbox. The interviewer wants to see that you understand why broad-stack tests are slow, brittle, and expensive, and why focused tests are fast and cheap. They are also checking if you know the pyramid is a heuristic about feedback loops and confidence, not a literal mandate.
The full answer
First, define the pyramid as a model for balancing automated tests by scope and cost. Second, explain the three layers: a wide base of unit tests for business logic and edge cases; a middle layer of service or subcutaneous tests that exercise APIs or just-below-UI integration points; and a narrow top of UI or end-to-end tests that verify critical user journeys. Third, tie each layer to concrete properties: unit tests run in milliseconds and pinpoint failures; service tests validate wiring and contracts without browser fragility; UI tests catch wiring gaps but should be minimal because they are slow and flaky. Fourth, state the defensive rule: if a high-level test finds a bug, write a unit test to reproduce it first so the regression lives at the cheap layer. Fifth, acknowledge exceptions: if your broad tests are fast, reliable, and cheap to maintain, the shape can shift.
The mistakes people make
Treating the pyramid as a rigid formula like seventy-twenty-ten. Conflating UI tests with end-to-end tests or customer-facing tests; these are orthogonal. Saying you should eliminate all UI tests; the pyramid argues for fewer, not zero. Recommending record-playback tools for the UI layer. Dismissing the model entirely without explaining the brittleness and runtime costs of broad-stack tests.
What usually comes next
How would you test a rich JavaScript frontend? The answer is mostly unit tests with Jasmine or similar, not Selenium. What if your service layer is just a thin CRUD wrapper over a database? You might compress the middle layer and invest more in contract tests. How do you handle microservices? The pyramid applies per service, but you still need a small set of cross-service smoke tests. What is the ice-cream cone anti-pattern? It is an inverted pyramid where most tests are slow UI tests, leading to long builds and low trust.
A concrete example
Imagine adding a discount-calculation feature to an e-commerce service. At the base, write unit tests for the pricing engine covering boundary values like zero, negative, and maximum discount thresholds. In the middle, add subcutaneous tests that POST a cart to the internal API and verify the returned total respects the discount rules. At the top, run one or two Selenium tests that apply a coupon through the checkout UI and confirm the final price displays correctly. If the UI test later fails because of a rounding bug, reproduce that rounding bug in a unit test before fixing it, so the fast suite catches regressions and the slow suite stays green.
Interview question
Which statement best captures the Test Pyramid's core guidance for testing strategy?
- a.It recommends eliminating UI tests entirely and relying only on unit and service tests.
- b.It is a heuristic for maximizing feedback speed by pushing tests to the cheapest, fastest layer that still delivers confidence.Correct
- c.It suggests verifying most business logic through UI tests because they exercise the full stack.
- d.It prescribes a fixed ratio such as 70% unit, 20% service, and 10% UI tests for every project.
Why? this is the answer
The Test Pyramid is a heuristic about feedback loops and economic confidence, not a rigid formula, so the correct answer emphasizes pushing tests to the fastest, cheapest appropriate layer. Option D is tempting but wrong because the card explicitly warns against treating the pyramid as a fixed seventy-twenty-ten mandate.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
- #testing
- #test-pyramid
- #agile
- #automation
- #senior
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on testing — each one lists the topics its interview covers.
See open roles