The Test Pyramid for Modern Product Teams

The test pyramid is decades old. It still works. Most teams that report testing as a productivity drag have built something that looks more like a test ice-cream cone or a test hourglass than a pyramid. Fixing the shape is usually the highest-leverage change a team can make in QA without hiring.

The pyramid in 2026

Fast tests at the bottom. Slow tests at the top. More tests at the bottom than the top. That's it.

What goes where

Unit tests (the foundation)

Test pure functions, business logic, and small components in isolation. No database, no network, no DOM rendering beyond what jsdom provides cheaply.

A unit test should:

• Run in under 100ms.
• Test one thing.
• Use no shared state between tests.
• Be deterministic. Same input, same output, every run.

Examples:

• A pricing calculator that takes a quote and returns a total.
• A date formatter that handles timezone edge cases.
• A reducer that handles the "add item to cart" action.
• A regex validator for invoice numbers.

Integration tests (the middle)

Test the seam between two pieces of your system. Most commonly: an API route end-to-end through to the database, or a frontend component talking to a mocked API.

An integration test should:

• Run in 1 to 3 seconds.
• Hit a real database (usually a per-test transaction that rolls back).
• Cover the happy path plus 2 to 4 failure cases.
• Use real auth where it matters.

Examples:

• POST /api/invoices writes a row to the database and returns the right shape.
• The "create user" flow hits the database and triggers a welcome email (mocked at the email-provider boundary).
• The frontend <InvoiceForm> submits valid data and renders the success state.

E2E tests (the cap)

Test critical user journeys through the whole stack, browser to database. Slow, fragile, and disproportionately expensive when over-used.

An E2E test should:

• Cover a critical journey only.
• Run in 10 to 30 seconds.
• Be stable. Flake rate under 1 percent.
• Mock anything that isn't part of your product (payment provider sandbox, email provider).

Examples (for a typical SaaS):

• Sign up, verify email, complete onboarding.
• Add a payment method, upgrade plan, see the new plan reflected.
• Create an invoice, send it, the recipient sees it.
• Reset password.
• Delete account.

That's 5 critical journeys. Maybe 10 to 15 if your product has more surfaces. Not 200.

The common failure modes

The ice-cream cone

Lots of E2E tests. A few integration tests. Almost no unit tests.

What it feels like: CI takes 25 minutes. Flake rate is 5 percent. Every refactor requires fixing 20 E2E tests. The team avoids refactoring.

The fix: identify the business logic inside the E2E paths. Extract it to pure functions. Test the pure functions with fast unit tests. Now the E2E suite can shrink to its real job.

The hourglass

Lots of unit tests. Lots of E2E tests. Almost no integration tests.

What it feels like: unit tests pass, E2E tests pass, production breaks because the contract between the API and the database had a subtle bug nobody covered.

The fix: write integration tests for every API route. Hit the real database. Cover the auth boundary, the validation boundary, and the database boundary.

The flat suite

All tests at the same speed. Usually because the team didn't separate fast tests from slow ones. CI runs everything every time.

The fix: split CI into "fast" (unit + integration) and "slow" (E2E). Fast on every PR. Slow on merge to main, plus a nightly run.

What to test, not just how much

A test is valuable when:

• It catches a real class of bug your customers would notice.
• It runs reliably and quickly.
• It explains the system's intent to a new engineer.

A test is noise when:

• It tests the framework, not your code (e.g. asserting React renders).
• It tests an implementation detail that's allowed to change.
• It has a 5 percent flake rate and gets retried until green.

Cut the noise. Trust the suite that's left.

Best practices for keeping the pyramid stable

• Test data factories, not fixtures. Factories build the data each test needs. Fixtures rot.
• One assertion per test where reasonable. Multiple assertions is fine if they're on the same operation.
• Page Object pattern for E2E. Selector changes happen in one place.
• Per-test database transactions that roll back. No cross-test pollution.
• Visual regression for design-system changes. Chromatic or Percy. Saves hours of manual review.
• Run tests in parallel. Modern test runners support it. Use it.

How Hashorn helps teams fix their test pyramid

Hashorn provides quality assurance, QA automation, and manual testing services. We often start an engagement by re-shaping a client's test pyramid, then layering on AI QA testing once the foundation is right. If you need a dedicated QA pod that owns the suite, our dedicated QA team engagement covers that.

Conclusion

The test pyramid in 2026 is still the right shape. The teams that struggle with testing aren't testing too much. They're testing the wrong things, at the wrong layer, with the wrong tools. Fix the shape first. The flake rate, the CI time, and the refactoring cost all follow.