Four Test Levels: Unit, Functional, Integration, End-to-End

A Different Cut Than the Failure Buckets

The five failure buckets classify a failure *after* it happens. Test levels are a complementary idea: they classify what a given *test* is actually capable of catching *before* anything fails, so a passing test suite doesn't quietly hide a gap nobody wrote a test for. A given test only tells you something if you know in advance the specific class of failure it's positioned to catch -- and, equally, the classes it has no way of catching.

Why the Integration Level Is Where Silent Failures Hide

This is the level worth dwelling on, because it's the one most teams skip. Each side of a handoff can sail through its own test while the connection between the two sides is still broken -- and neither unit test, run on its own, will ever surface that.

Here's a concrete shape of that failure: an order-lookup function is unit-tested in isolation and correctly returns a structured order record -- it passes. A response-formatter function is functionally tested by handing it a hand-built order record directly, and it correctly renders a customer-facing summary from that record -- it passes too. Wire the two together, though, and the order-lookup function actually returns its record wrapped inside a status envelope ({"status": "ok", "data": {...}}), while the formatter was written expecting the bare record itself. The formatter chokes silently on the mismatch and falls back to a generic "order not found" message even though the lookup succeeded. Neither test sees this: the lookup function is doing exactly what its unit test checks, and the formatter is doing exactly what its functional test checks against a well-formed input. The gap lives specifically in the never-written contract *between* the two functions, and only a test exercising both together, with real data flowing from one into the other, would catch it.

PASS  test_lookup_unit             returns a valid order record
PASS  test_formatter_functional    renders a summary from a well-formed record
FAIL  test_full_flow_e2e
  step 1 lookup_order(id)      ok  -> {"status": "ok", "data": {...}}
  step 2 format_summary(resp)  ok  -> formatter reads resp directly, not resp["data"]
  step 3 assert summary        FAIL -> "order not found" shown despite a successful lookup

Complementary to, Not a Replacement For, Reproduce-Inspect-Localize

The four test levels and the reproduce-inspect-localize procedure (4.2.1) answer different questions and work together, not as alternatives. Test levels are a *design-time* discipline: deciding in advance which level of test would catch a given class of bug, so the gap is closed before it ships. Reproduce-inspect-localize is a *post-hoc* discipline: given a failure that already happened in the wild, working backward to find which layer owns it. A missing integration test is exactly the kind of gap that reproduce-inspect-localize will eventually surface in production -- the fix, once localized, is often to add the integration test that should have existed already, so the same seam-level break can't ship silently again.

Common exam traps

• Assuming that unit tests plus functional tests passing means the system works. Both can pass while the handoff between the two components they cover is still broken -- that gap is precisely what the integration level exists to close.
• Treating end-to-end tests as sufficient on their own because they exercise the whole flow. They catch that *something* broke but are the hardest level to localize a failure within -- they don't tell you *where* in the chain the break occurred.