Glossary
Unit vs Integration vs End-to-End Testing
These describe how much of the system a test exercises. Unit tests check one function in isolation. Integration tests check several units together across a real boundary. End-to-end tests check the whole app from the outside.
The three terms describe scope, not importance — a unit test isn't "smaller" in value than an end-to-end test, just narrower in what it exercises.
| Type | Scope | Speed | Catches |
|---|---|---|---|
| Unit | One function or module, dependencies faked | Milliseconds | Logic errors in a single unit |
| Integration | Several units, a real boundary (e.g. a database) | Seconds | Wiring mistakes a unit test can't see |
| End-to-end | The whole system, from the outside | Seconds to minutes | "Does this actually work for a user" |
Why the distinction matters
Each layer catches a different class of bug. A unit test can't tell you the sign-up button isn't wired up — no unit test drives the button. An end-to-end test can tell you that, but it's too slow and coarse to pinpoint exactly which calculation is wrong. Good coverage uses all three deliberately rather than piling everything into one layer.
In practice
The testing pyramid is the classic model for how many of each to have, and choosing your test distribution covers making that decision by risk rather than by a fixed ratio. Autonomous testing adds a fourth option specifically for the end-to-end layer — see the end-to-end testing guide.
See also
See how this plays out in practice — start a free run or read the autonomous testing guide.