Unit vs integration vs E2E tests

The three differ in how much of the system each one exercises, and that choice drives everything else about them.

Unit tests cover one function or component in isolation, with its dependencies replaced by fakes. They run in milliseconds and point straight at the broken line, but they prove nothing about how pieces fit together.

test("applies member discount", () => {
  expect(priceFor(100, { member: true })).toBe(90);
});

Integration tests cover several real parts working together — a component with its store, or an API route with a real test database. Slower, but they catch the errors unit tests structurally cannot: a wrong argument order, a mismatched shape between two modules, a query that never matched.

End-to-end tests drive the real application in a browser, as a user would. They are the only tests that prove the whole thing works, and also the slowest and most brittle: a timing change or a moved button breaks them.

How many of each

The classic advice is a pyramid — many unit, fewer integration, a handful of E2E. In front-end work a "testing trophy" shape is often better: integration tests give the best confidence per unit of effort, because rendering a component with its real children catches far more than testing a pure function does.

What matters more than the ratio: E2E tests should cover only your critical paths — sign up, checkout, the one flow that must never break. Trying to test everything end to end produces a suite so slow and flaky that people stop trusting it, which is worse than having fewer tests.