Also known as: end-to-end testing "E2E"
End-to-end (E2E) testing drives the whole system the way a user would, from input all the way to final output — the highest-confidence test, but slow and kept few.1
What it is
An end-to-end test treats the system as a black box and verifies a complete user-facing flow: it submits real input, lets the request travel through every layer — frontend, backend, API, database, external services — and asserts on the final result. Because nothing is stubbed, a passing E2E test is strong evidence the product actually works the way a user will experience it, including the integration points that unit and integration tests can miss.1
The trade-off
That confidence is expensive. E2E tests are slow (they spin up the whole system), brittle (any layer changing can break them), and costly to maintain. They also localize poorly: a failure tells you something broke, not where. For all these reasons they sit at the narrow tip of the test pyramid — you keep only a thin layer of them, covering the most important flows. The classic anti-pattern is the “inverted pyramid,” a suite made mostly of slow E2E tests, which becomes slow and flaky and tells you little about the cause of a failure.
How it fits
E2E complements the faster layers beneath it: many unit tests at the base, fewer integration tests in the middle, a handful of E2E on top. They are usually run in a CI/CD pipeline before release rather than on every commit, and even an E2E suite may use mocking for genuinely external dependencies. Like all tests, they contribute to code coverage but are no substitute for sharp, well-asserted checks lower down, and they can be written test-first in the TDD spirit.
Sources
-
System testing — Wikipedia, on testing a complete, integrated system end to end as a user would. ↩ ↩2