Challenge 3: Explaining the Pyramid's Trade-off — Possible Solution
====================================================================

Even though E2E tests are the most realistic — they exercise the
actual application in an actual browser across a full user journey —
a team wouldn't write nothing but E2E tests because that realism comes
at a real, compounding cost along two dimensions this chapter named
directly: SPEED and NUMBER.

E2E tests are slow: each one has to boot a real (or real-like) browser,
navigate through multiple real pages, and wait for real network/render
timing — a suite of hundreds of E2E tests can take many minutes or
longer to run, compared to a unit test suite of the same size finishing
in seconds. This matters enormously for everyday development, where a
developer wants fast feedback after every small change; a slow test
suite gets run less often, or only in CI, delaying when a broken change
is actually caught.

E2E tests are also expensive to write and maintain, and by nature
cover LARGE swaths of the app in one test — which means when an E2E
test fails, it's often much harder to pinpoint exactly WHERE in that
large surface area the actual problem is, compared to a small, focused
unit test that fails and points at one specific function immediately.

This is precisely the trade-off the testing pyramid visualizes: unit
tests are fast, numerous, and pinpoint failures precisely, but each one
proves very little about whether the app actually works AS A WHOLE for
a real user; E2E tests prove the most about real-world correctness, but
are slow, expensive, and vague about the exact cause when they fail. A
healthy test suite uses many fast unit tests to catch most problems
quickly and precisely, a moderate number of component/integration
tests to verify pieces work together, and a small number of E2E tests
to catch the kind of cross-cutting, real-environment problems the other
layers structurally cannot see — using each layer for what it's
actually good at, rather than relying on just one.