Unit vs integration vs end-to-end tests

Published 21 October 2026

A test exists to fail before your users do. The question is never "should we test this", it is which kind of test catches this bug most cheaply. There are three kinds, and the difference between them is how much of the real system each one runs:

• A unit test runs one function or class on its own, with nothing real around it: no database, no network, no disk. It takes a millisecond and tells you exactly which function broke.
• An integration test runs your code together with something real it depends on: a real Postgres, a real queue, a real HTTP client against a sandbox. It takes tens or hundreds of milliseconds and catches the bugs that live in the seams.
• An end-to-end test (E2E) drives the whole product the way a user would, usually a real browser clicking through real pages against a deployed copy of the app. It takes seconds per test and catches what nothing else can, at the highest cost.

Which test catches which bug#

The best way to feel the difference is to look at bugs that really happen, and ask which is the cheapest test that would have stopped each one.

Notice the pattern. Logic bugs (formatting, rules, calculations) are cheapest to catch with unit tests. Seam bugs (SQL against a real database, time zones, config, the contract with a payment gateway) only show up when the real thing is there, so they need integration tests. Experience bugs (a button you can't reach, a page that never loads) need a browser.

How many of each#

Mike Cohn drew the test pyramid in 2009: lots of unit tests at the bottom, fewer integration tests in the middle, a handful of E2E tests at the top. The shape follows the cost. Unit tests are fast and precise, so have many. E2E tests are slow and break for reasons that have nothing to do with your change, so keep them for the paths that matter most.

Kent C. Dodds pushed back in 2018 with the testing trophy, which puts the most weight on integration tests. His point was that a pile of unit tests full of mocks can all pass while the app is broken, because the mocks agree with your code, not with reality. That is exactly what happened in two of the bugs above.

Both are right about different code. A practical rule that works for most backend services:

• Unit tests for logic with many cases: pricing, permissions, parsing, state machines.
• Integration tests for every query, every external call and every queue, against real dependencies running in containers.
• E2E tests for the five to ten user flows that make money or lose trust: sign up, log in, search, checkout, cancel. Not every page.

How teams write them today#

This is a typical TypeScript setup in 2026: Vitest for unit tests, Testcontainers to start a real Postgres in Docker for integration tests, and Playwright for the browser. The same ideas carry over to Python (pytest, Testcontainers for Python, Playwright for Python) and Java (JUnit, Testcontainers, Playwright).

import { describe, it, expect } from 'vitest'
import { applyCoupons } from './coupons'
 
// One table, many cases, under 10 ms. Rules like this are what unit tests are for.
describe('applyCoupons on a ₹1,000 cart', () => {
  it.each([
    [[], 1000],
    [['SAVE10'], 900],
    [['FLAT50'], 950],
    [['SAVE10', 'FLAT50'], 900], // only one applies: the better one
  ])('%j gives %i', (codes, total) => {
    expect(applyCoupons(1000, codes)).toBe(total)
  })
})

Three habits make these suites work on a real team:

1. Find elements the way users do. getByRole('button', { name: 'Pay' }) survives a redesign; a CSS selector like .btn-primary > span breaks when someone renames a class. Testing Library made this style popular and Playwright built it in.
2. Each test sets up its own data. Tests that depend on each other, or on what an earlier test left in the database, pass alone and fail together.
3. Treat flaky tests as bugs. A test that fails sometimes for no reason teaches everyone to press "re-run" and ignore red. Google reported in 2016 that about 1.5% of its test runs were flaky, and that almost 16% of its tests had failed that way at least once. Quarantine a flaky test the day you see it, and fix or delete it within the week.

In the interview#

Checkpoint#