Explain the Test Pyramid and how it guides testing strategy

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.

Source: martinfowler.com