Testing Strategy: The Test Pyramid

Question 1

What does a unit test typically verify?

Accepted Answer

That a single function or class behaves correctly in complete isolation — Unit tests target the smallest testable piece of code — a single function, method, or class — in isolation. All external dependencies like databases or network calls are replaced with fakes (mocks or stubs) so the test runs in milliseconds and failures point to exactly one place in the code.

Question 2

Why should unit tests make up the largest share of your test suite?

Accepted Answer

Because they run in milliseconds, can be thousands of them, and failures pinpoint the exact broken function — Unit tests are fast (milliseconds each), cheap to write and maintain, and their failures are precise — if a unit test breaks you know the exact function at fault. Having thousands of them keeps CI fast. Integration and e2e tests are valuable but slower and more expensive, so you have far fewer of them.

Question 3

Which scenario is BEST suited for an integration test rather than a unit test?

Accepted Answer

Checking that a write endpoint handler actually persists a row to a real test database — Integration tests verify that multiple real components work together — a controller talking to a real (test) database is a classic example. The other scenarios involve a single unit in isolation and are better covered by fast unit tests.

Question 4

What is a "flaky test"?

Accepted Answer

A test that sometimes passes and sometimes fails for reasons unrelated to the code under test — A flaky test is one whose outcome is non-deterministic — it passes on one run and fails on the next even though no code changed. Flakiness is far more common in e2e tests because they depend on real browser timing, network latency, and external services, all of which can vary unpredictably.

Question 5

In the context of unit testing, what does "mocking" a dependency mean?

Accepted Answer

Replacing a real dependency with a controlled fake that returns predetermined responses — A mock (or stub) is a fake stand-in for a real dependency — a fake database, a fake HTTP client, a fake file system. It returns whatever the test needs it to return, instantly and without side effects. This is what makes unit tests so fast: they never touch real I/O.

Question 6

What is the "ice cream cone" anti-pattern in testing?

Accepted Answer

A suite with mostly slow end-to-end tests and very few unit tests — the inverted pyramid — The ice cream cone is the test pyramid turned upside down. Teams that skip unit tests and rely on slow, broad e2e tests end up with a suite that takes hours, breaks randomly (flakiness), and gives poor signal about where bugs are. It is the most common anti-pattern in projects that grew without a testing strategy.

Question 7

Why are end-to-end tests at the TOP (narrowest part) of the test pyramid?

Accepted Answer

Because you should have very few: they are slow, brittle, and expensive relative to unit or integration tests — The narrow top represents having few e2e tests by design. Each e2e test can take tens of seconds to minutes, requires a running browser and a full stack, and is more prone to flakiness. They are valuable for validating critical user journeys end-to-end, but you cannot afford to have hundreds of them without destroying CI speed.

Question 8

What does "test isolation" mean and why does it matter?

Accepted Answer

Each test starts in a clean state with no shared data or side effects from other tests, so failures are independent and repeatable — Test isolation means each test sets up its own state, runs independently, and tears down after itself. An isolated test failure tells you exactly what broke — it cannot be caused by a previous test leaving dirty state. Unit tests are naturally isolated because they mock all I/O; integration and e2e tests require more care to achieve isolation.

Question 9

A team has 5 unit tests, 200 integration tests, and 500 e2e tests. Which problem will they most likely experience?

Accepted Answer

A slow, brittle test suite — the ice cream cone anti-pattern — where CI takes hours and breaks randomly — This is a textbook ice cream cone: the vast majority of tests are slow e2e tests. With 500 e2e tests each taking 30–60 seconds, CI could take many hours. The suite will also be brittle because e2e tests are prone to flakiness. Flipping the ratio — many unit tests, fewer integration, very few e2e — fixes both problems.

Question 10

What does "100% code coverage" mean, and what is its main limitation?

Accepted Answer

Every line of code has been executed by at least one test — but executing a line is not the same as verifying the code is correct — 100% code coverage means every line (or branch) was touched by a test at least once. The critical limitation: a test can execute a line without asserting anything meaningful about it, so coverage says nothing about correctness. A test suite can have 100% coverage and still miss important bugs — the quality of assertions matters as much as coverage percentage.

Test Pyramid Visualizer
Healthy Pyramid

Where in the pyramid?

Test your knowledge

What does a unit test typically verify?

The short version

Interview Questions

References & Further Reading

Related topics

Love this visualization?

Testing Strategy: The Test Pyramid

Test Pyramid VisualizerHealthy Pyramid

Where in the pyramid?

Test your knowledge

What does a unit test typically verify?

The short version

Interview Questions

References & Further Reading

Related topics

Love this visualization?

Test Pyramid Visualizer
Healthy Pyramid