What Is the Right Mix of Unit, Integration, and End-to-End Tests in CI?

The right mix for most teams is a **broad base of fast unit tests, a smaller middle layer of integration tests, and a thin top layer of end-to-end (E2E) tests** — the classic testing pyramid. The reason is economic: tests that are cheap to write, fast to run, and stable should dominate, while slow, brittle, expensive tests should be used sparingly and only where nothing else gives you confidence.

## Why the Pyramid, Not the Ice-Cream Cone

The failure mode to avoid is the inverted pyramid — the "ice-cream cone" — where a team has a handful of unit tests and relies on a huge pile of slow UI tests. That suite is slow, flaky, and hard to debug: a single failure could come from anywhere in the stack. The pyramid inverts the cost curve so most of your signal comes from tests that run in milliseconds.

Think in terms of three properties for each test:

- **Speed** — how long it takes to run.

- **Stability** — how often it fails for reasons unrelated to the code.

- **Diagnostic precision** — how quickly a failure tells you what broke.

Unit tests win on all three; E2E tests lose on all three but uniquely verify that the whole system actually works together.

## The Three Layers

**Unit tests** verify a single function, class, or module in isolation, with collaborators stubbed. They should be the overwhelming majority of your suite, run in seconds locally, and gate every commit. Good unit tests are the fastest feedback loop a developer has.

**Integration tests** verify that components work together — your code plus a real database, a real message queue, or two services talking over HTTP. They are slower because they involve I/O, so you want fewer of them, focused on the seams where bugs actually hide: serialization, queries, transactions, and contracts between modules.

**End-to-end tests** drive the whole application the way a user would — through the UI or public API, against a fully deployed environment. They give the highest confidence and the lowest precision. Reserve them for your handful of business-critical journeys: sign-up, checkout, the core action your product exists to perform.

## How to Choose the Numbers

There is no universal ratio, and anyone quoting an exact percentage is guessing about your context. Use principles instead:

1. **Push tests down the pyramid.** Before writing an E2E test, ask whether an integration or unit test would catch the same bug. Usually it would.

2. **Cap your E2E suite by runtime, not count.** If the full E2E run blows your CI time budget, you have too many — consolidate or move coverage down.

3. **Cover each behaviour once at the right level.** Duplicating the same assertion across all three layers wastes runtime and multiplies maintenance.

4. **Let risk guide the top.** A payment flow deserves an E2E test; a tooltip does not.

## Wiring It Into CI

Structure your pipeline so feedback arrives fastest where failures are most likely:

- Run **unit tests on every push**, ideally in under a couple of minutes.

- Run **integration tests on every pull request**, parallelised across runners.

- Run **E2E tests on merge to the main branch or before deploy**, not on every commit, since they are slow.

- Fail fast: if unit tests are red, do not waste runners on E2E.

This staging means developers get a signal within minutes, and the expensive checks only run when the cheap ones have already passed.

## A Common Anti-Pattern

Teams often over-test trivial code (getters, framework glue) and under-test the gnarly integration seams. Coverage percentage encourages this because trivial code is easy to cover. Judge your suite by whether it catches the bugs you actually ship, not by a number on a dashboard. Building products at scale, as we do at neart.ai, makes the value of testing the seams — not the trivia — very obvious.

## Practical Takeaway

Keep unit tests as the broad, fast base of your pyramid; use integration tests for the seams between components; and reserve a thin layer of end-to-end tests for your few business-critical journeys. Push every new test as far down the pyramid as it can go, and stage them in CI so the cheapest checks fail first.