Test Pyramid Strategy

How many tests, of which kind, and why

The pyramid is a ratio heuristic, not a rule. Five layers — unit, integration, contract, e2e, exploratory — each with a different speed-coverage-cost triangle. Plus an explicit ratio-by-architecture table so your pyramid fits your system, not a stock photo.

The ice-cream cone anti-pattern: many teams end up inverted — lots of e2e, few unit. Because e2e catches everything, it feels safe. But it's slow (30-min suites), flaky (timing), and expensive (real browsers). When you see “we have 200 e2e tests and 40 unit tests” — the pyramid has fallen on its head. Fix by pushing coverage DOWN one layer at a time.

1. Unit — functions in isolation

Test a single function with mocked collaborators. Milliseconds per test.

Speed

< 10 ms per test; 1000 tests in 10 s

What it catches

Pure functions, business rules, parsers, validators, state machines — anything that's a self-contained transformation.

When to reach for it: Base layer. For every new function with branching logic, add unit tests BEFORE moving higher. 60-70 % of all tests should live here.

Smell: Mocking 5+ collaborators to test one function = the function has too many responsibilities. Split it before adding more mocks.

2. Integration — multiple modules together

Test a cluster of real modules (no mocks except the outermost edge) — e.g. API route + DB + cache. Seconds per test.

Speed

100 ms – 2 s per test; 100 tests in 2 min

What it catches

Wiring, SQL queries, cache invalidation, middleware chains, transactional boundaries — where units meet.

When to reach for it: Immediately above unit. 15-25 % of the suite. If your bug-search for 'wrong SQL' or 'middleware order' takes hours, this layer is understaffed.

Smell: Integration tests that still mock the DB are just large unit tests with extra cost. Integration means you lose the mock OR you drop the layer.

3. Contract — verify the shape at the boundary

Consumer-driven: record what your app sends/expects; verify the producer matches. Seconds per test.

Speed

100 ms – 1 s per test; fast because no full stack runs

What it catches

API contracts between services, GraphQL schemas, event schemas — anything that crosses a team/service boundary.

When to reach for it: Mandatory above 2 services. 5-10 % of the suite, but prevents 50 % of 'why did staging break' incidents. Pact, Schemathesis, OpenAPI diff.

Smell: Copy-pasting response fixtures into both services and updating both on every change. You have contract tests without the contract.

4. End-to-end — real browser, real backend

Drive a real browser against a real deployed stack. Proves the system works for a user.

Speed

10 s – 2 min per test; flaky, expensive, slow

What it catches

Critical user journeys only: signup, checkout, core workflow. NOT comprehensive coverage — NOT a replacement for unit.

When to reach for it: Top of pyramid. 5-10 % of the suite. Cover the 'if this breaks, revenue stops' paths; everything else goes in lower layers.

Smell: 20+ e2e tests per feature. This is the inverted pyramid (ice-cream cone) — you're testing through the slowest possible layer because lower layers don't exist. Fix by pushing down.

5. Exploratory — unscripted, time-boxed investigation

Not part of the pyramid — the ground it stands on. Scripted tests find known bugs; exploratory finds unknown ones.

Speed

30 – 90 min per session; yields bugs AND test candidates

What it catches

Anything your scripted tests don't anticipate. Edge cases, UX papercuts, accessibility issues, multi-tab surprises.

When to reach for it: At every release. New features get 1-2 charters; bug reports inform the next charter. Findings then get scripted into the appropriate layer.

Smell: 'We don't have time for exploratory testing' = the team will find the same bugs after release, when they cost 10× more to fix. Book the time.

Ratio by architecture

The right pyramid depends on what you're building. Use these as starting points and calibrate from actual data (which layer catches which bugs over the past quarter).

Context	Unit	Integration	Contract	E2E	Why
Monolith (single service, shared DB)	70 %	20 %	0 %	10 %	No service boundary = no contract tests. Integration covers cross-module.
Microservices (5+ services)	55 %	20 %	15 %	10 %	Contract layer becomes critical — replaces most of the cross-service integration that's too expensive to run.
Pure frontend SPA	40 %	30 %	15 %	15 %	Component / integration tests swap places — UI logic needs component testing (RTL, Vitest component).
Library / SDK	85 %	10 %	5 %	0 %	No UI, no deploy — contract is the API contract to your consumers, via semver + type tests.

These numbers exclude exploratory — that's time-boxed investigation, measured in hours per release, not test count.

Where does THIS test go?

A decision tree for placing any new test in the right layer:

Does it verify one pure function with no I/O? → Unit.
Does it verify a real I/O path (DB query, HTTP round-trip) in your own service? → Integration.
Does it verify the shape of a request / response across a service boundary? → Contract.
Does it verify a user-visible journey through the real UI? → E2E.
Can you NOT describe what it's verifying in one sentence? → Don't write it; put it on the exploratory backlog instead. Scripted tests need sharp intent.

← Back to all Labs

How many tests, of which kind, and why

Ratio by architecture

The right pyramid depends on what you're building. Use these as starting points and calibrate from actual data (which layer catches which bugs over the past quarter).

Context	Unit	Integration	Contract	E2E	Why
Monolith (single service, shared DB)	70 %	20 %	0 %	10 %	No service boundary = no contract tests. Integration covers cross-module.
Microservices (5+ services)	55 %	20 %	15 %	10 %	Contract layer becomes critical — replaces most of the cross-service integration that's too expensive to run.
Pure frontend SPA	40 %	30 %	15 %	15 %	Component / integration tests swap places — UI logic needs component testing (RTL, Vitest component).
Library / SDK	85 %	10 %	5 %	0 %	No UI, no deploy — contract is the API contract to your consumers, via semver + type tests.

These numbers exclude exploratory — that's time-boxed investigation, measured in hours per release, not test count.

Where does THIS test go?

A decision tree for placing any new test in the right layer:

Does it verify one pure function with no I/O? → Unit.
Does it verify a real I/O path (DB query, HTTP round-trip) in your own service? → Integration.
Does it verify the shape of a request / response across a service boundary? → Contract.
Does it verify a user-visible journey through the real UI? → E2E.
Can you NOT describe what it's verifying in one sentence? → Don't write it; put it on the exploratory backlog instead. Scripted tests need sharp intent.