Testing pyramid

Overview

The testing pyramid is a strategy for balancing automated tests. The wide base is many fast, isolated unit tests of individual functions and classes. The middle layer is fewer integration tests that verify components working together (service plus database, API plus queue). The narrow top is a small number of end-to-end tests that drive the whole system like a user would.

The shape reflects cost and speed. Unit tests run in milliseconds and pinpoint failures; end-to-end tests are slow, brittle, and expensive to maintain but catch problems nothing else can. A healthy suite gives fast feedback on every commit and high confidence before release. The anti-pattern is the 'ice cream cone', with mostly manual and end-to-end tests and few unit tests.

When to use it

• Designing a test strategy for a service or product.
• Deciding what to test at which level.
• Speeding up slow, flaky CI pipelines.
• Interview discussions of quality in system and LLD designs.

Where it shows up in interviews

Where it is used in real software

Key terms

Unit test

Tests one unit in isolation, fast and deterministic.

Integration test

Tests components together with real dependencies such as databases.

End-to-end test

Tests the full system through its external interface.

Contract test

Verifies services agree on API contracts without full end-to-end setup.

Flaky test

Passes and fails nondeterministically.

How it works, step by step

1. 1
   Unit test business logic

   Pure rules, calculations, state transitions, with fakes for dependencies.

2. 2
   Integration test boundaries

   Repository queries against a real database, message handlers against a real broker.

3. 3
   Contract test service interfaces

   Consumer-driven contracts catch breaking API changes early.

4. 4
   End-to-end test critical journeys

   A handful of flows such as sign-up, checkout, and payment.

5. 5
   Run layers at the right time

   Units on every commit, integration in CI, end-to-end before and after deploys.

Test levels compared

For a checkout feature

Push each test to the lowest level that can catch the bug; reserve end-to-end tests for critical paths.

Implementation

1import { describe, expect, it } from "vitest";2 3// Unit: pure logic, no I/O4describe("PricingEngine", () => {5  it("applies coupon before tax", () => {6    const engine = new PricingEngine({ taxRate: 0.1 });7    expect(engine.total([{ priceCents: 1000, qty: 2 }], { coupon: "SAVE10" })).toBe(1980);8  });9});10 11// Integration: real database via Testcontainers12describe("OrderRepository", () => {13  it("persists and loads an order", async () => {14    const pg = await new PostgreSqlContainer("postgres:16").start();15    const repo = new OrderRepository(await connect(pg.getConnectionUri()));16    const id = await repo.save({ userId: "u1", totalCents: 1980 });17    expect(await repo.find(id)).toMatchObject({ userId: "u1", totalCents: 1980 });18    await pg.stop();19  });20});21 22// End-to-end: one critical journey (Playwright)23// test("checkout", async ({ page }) => {24//   await page.goto("/products/42"); await page.click("text=Add to cart");25//   await page.click("text=Checkout"); await page.fill("#card", "4242424242424242");26//   await page.click("text=Pay"); await expect(page.getByText("Order confirmed")).toBeVisible();27// });

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Ice cream cone (mostly manual and UI tests).

  Fix: Move checks down to unit and integration levels.

• Ignoring flaky tests.

  Fix: Quarantine and fix them quickly; flakiness destroys trust in CI.

• Testing implementation details.

  Fix: Test behavior through public interfaces so refactoring does not break tests.

Interview questions

Practice problems