Learn the vocabulary of favoring many fast unit tests over a few slow, broad end-to-end tests.
0 / 5 completed
1 / 5
At standup, a dev mentions a testing strategy with many fast, narrow unit tests at the base, fewer integration tests in the middle, and only a small number of slow, broad end-to-end tests at the top. What is this shape called?
The test pyramid describes a testing strategy shaped like a pyramid: many fast, narrow unit tests forming the wide base, fewer integration tests in the middle testing how components interact, and only a small number of slow, broad end-to-end tests at the very top exercising the whole system together. Mutation testing is an unrelated technique that checks test suite quality by introducing small code changes and seeing if any test fails, not a description of test-type proportions. This shape reflects a deliberate tradeoff, favoring many cheap, fast, isolated tests over relying heavily on a small number of expensive, slow, broad ones.
2 / 5
During a design review, the team decides a new feature's core business logic should be covered primarily by unit tests, with only one or two end-to-end tests confirming the feature works through the full system. Which capability does this distribution provide?
This distribution provides fast, cheap feedback on most bugs from the unit tests, since a unit test runs in milliseconds and can isolate a specific piece of logic precisely, while the handful of end-to-end tests exist just to confirm the pieces are correctly wired together in the full running system, without needing to re-test every individual logic case at that much slower, more expensive, and more brittle layer. Treating every test type as equally fast and cheap ignores exactly why the pyramid shape exists in the first place. This front-loading of cheap unit tests, backed by a thin layer of broader tests, is what keeps a test suite's overall feedback loop fast even as the codebase grows.
3 / 5
In a code review, a dev notices a codebase has very few unit tests but an enormous, slow suite of end-to-end browser tests covering nearly every business logic case, an inverted shape relative to the classic test pyramid. What does this represent?
This is a test-suite anti-pattern, sometimes called an ice-cream-cone shape, since it inverts the pyramid by relying heavily on slow, brittle end-to-end tests to cover cases that would run far faster and more reliably as unit tests, dragging out feedback cycles and making the suite expensive to maintain as the browser-level tests become flaky. A code smell is a related but distinct, broader concept about surface-level indicators of deeper design issues, not specifically about test-type proportions. This inverted shape is exactly the failure mode the test pyramid's guidance is meant to help teams avoid.
4 / 5
An incident report shows a team's CI pipeline took over an hour to run and frequently failed due to flaky browser-based tests, because the vast majority of test coverage lived in slow end-to-end tests instead of fast unit tests closer to the actual business logic. What practice would prevent this?
Rebalancing the suite toward the test pyramid's shape, moving most business-logic coverage down into fast, isolated unit tests and reserving the slower end-to-end layer for just a small number of genuinely critical end-to-end user flows, directly addresses both the long CI runtime and the flakiness described in this incident, since unit tests are inherently faster and far less prone to environmental flakiness than a full browser-driven test. Continuing to rely primarily on the slow end-to-end layer for the bulk of coverage is exactly what caused the hour-long, frequently failing pipeline. This rebalancing toward the pyramid's proportions is the standard fix once a test suite's shape has inverted and started dragging down the team's feedback loop.
5 / 5
During a PR review, a teammate asks why the team pushes for more unit test coverage instead of just relying on a comprehensive suite of end-to-end tests, since end-to-end tests exercise the real system exactly as a user would experience it. What is the reasoning?
End-to-end tests are genuinely valuable for confirming the whole system is correctly wired together end to end, but they're inherently slower to run and more brittle, since they depend on a fully running environment with more moving parts that can fail for reasons unrelated to the actual logic being tested. Relying on them for the bulk of business-logic coverage makes the overall suite's feedback loop painfully slow and prone to unrelated flakiness, while the same logic covered by unit tests runs in a fraction of the time and fails only when that specific logic is actually broken. The tradeoff is that unit tests alone can't catch an integration or wiring problem between components, which is exactly why the pyramid still keeps a thinner layer of integration and end-to-end tests rather than eliminating them entirely.