What are the four functional test levels, and how do they differ?

The long answer

Functional test levels describe where in the system a test runs and how much of it gets exercised.

Unit testing is the smallest scope: one function or class, tested completely in isolation, with dependencies like databases or external calls mocked out. Owned by developers, since it needs code-level access.

Integration testing checks that real components actually work together, nothing mocked. It can isolate just one connection point, like an API talking to a real database, or chain together several. The scope is flexible — the defining trait is real components, real handoffs.

System testing treats the entire application as one sealed black box, tested from outside with no internal code knowledge. It checks the whole product against its requirements, from a user’s perspective — does every major feature work, does navigation work, do errors display correctly, is performance acceptable. It’s contained to one application’s boundary, not deliberately reaching into other separate systems.

End to end testing walks a full real user journey across every layer in sequence — starting typically at the UI since that’s the real entry point, then through the API, then any external systems like a payment gateway, then the database, then any downstream systems like an email service. It deliberately proves the whole chain holds together, not just that each piece works alone.

Test pyramid vocabulary: unit tests form the wide base (~70%), integration ~20%, end to end/UI at the thin top (~10%) — commonly said as 70/20/10. The inverse — mostly slow E2E tests, few unit tests — is the ice-cream-cone anti-pattern, a red flag for slow, flaky, expensive suites.