The Testing Pyramid & E2E Testing

The plain-language idea

The testing pyramid describes a healthy ratio of test types, not a strict hierarchy of importance:

• Unit tests (the base, most numerous) — one function or component in isolation. Fast (milliseconds), cheap to write, pinpoint exactly what broke.
• Integration tests (the middle) — several pieces working together (a component plus the hooks it uses, an API route plus the database). Slower, but catch bugs unit tests structurally can't see — the seams between pieces.
• End-to-end (E2E) tests (the top, fewest) — a real browser driving the actual app through a real user flow (Playwright, Cypress): "sign up, add an item to cart, check out." Slowest and most brittle, but the closest thing to proof the whole system actually works together.

// E2E, with Playwright — drives a real browser
test("user can complete checkout", async ({ page }) => {
  await page.goto("/products/42");
  await page.click("text=Add to cart");
  await page.click("text=Checkout");
  await page.fill("[name=card]", "4242424242424242");
  await page.click("text=Place order");
  await expect(page.locator("text=Order confirmed")).toBeVisible();
});

Unit tests: many, fast, cheap — test one function in isolation.

BackNext

What people usually miss

Watch out

• An "inverted pyramid" (mostly E2E, few unit tests) is a real, common anti-pattern — it feels like more confidence per test, but the suite becomes slow, flaky, and painful to maintain, and a failure often doesn't tell you where the bug is, just that something, somewhere, broke.
• The React Testing Library philosophy (from the React track's testing lesson) blurs unit and integration a bit on purpose — testing a component through user-facing behavior naturally exercises its hooks and child components together, which is intentionally closer to an integration test than a strict, isolated unit test.
• E2E tests are the right tool for genuinely cross-cutting concerns — authentication flows, payment flows, anything where the real risk is in the pieces connecting correctly, not in any single piece's internal logic.

Why this matters in interviews

"How would you decide what to unit test versus E2E test for a checkout flow?" is a practical, common question — a strong answer explains the pyramid's ratio reasoning (speed, cost, flakiness) rather than just naming the three test types.