Challenge 1: Classifying Test Types — Possible Solution
====================================================================

(a) validateEmail(string) — UNIT TEST.
No DOM, no rendering, no component involved at all — it's a plain
function taking a string and returning a value (likely a boolean).
This is exactly this chapter's definition of a unit test: isolated
logic, tested in complete isolation from the UI.

(b) A Button component renders its label text — COMPONENT TEST.
This requires actually rendering a real component and inspecting what
appears — a single, isolated piece of UI, not a plain function and not
multiple pieces working together. This is squarely this course's
primary focus starting Chapter 3.

(c) A full checkout flow across three pages in a real browser — E2E
TEST. This exercises the entire real application, across multiple
pages/screens, in an actual (or actual-like) browser — the defining
trait of an E2E test, and exactly the kind of test this chapter
explicitly places out of this course's scope (Playwright/Cypress
territory).

WHY THIS WORKS AS AN ANSWER
------------------------------
The classifying question in each case is "how much of the real system
is actually exercised, and does it require a browser/DOM at all?" —
(a) needs neither a DOM nor multiple pieces (unit), (b) needs a DOM but
only one isolated piece (component), and (c) needs a full real
environment across multiple screens (E2E) — mapping directly onto the
three points on this chapter's testing pyramid that these examples
were chosen to represent.