A pure backend function is easy to test: give it an input, check the output. A UI component is judged by something less direct — what a real person can see and do with it. This chapter lays out why that difference matters, and introduces the vocabulary — the testing pyramid, and the four common types of tests — that the rest of this course is built on.

Why Frontend Code Needs Its Own Testing Approach

A component doesn't just return a value — it renders DOM, responds to clicks and typing, and often waits on something asynchronous (an API call resolving, a loading spinner disappearing) before the "real" result even appears. Correctness for a UI component means: does the right thing appear on screen, and does it respond the way a real user would expect when they interact with it? That's a fundamentally different question than "does this function return the right number," and it needs its own set of tools and habits — the subject of this entire course.

The Testing Pyramid

A classic model for thinking about a test suite's shape, from the bottom up:

The shape is a trade-off, not an accident: tests closer to the real user experience are more convincing when they pass, but slower to run and more expensive to write — which is exactly why there are usually far fewer of them.

The Four Types of Tests, Concretely

This Course's Toolchain

Chapter 2 introduces Jest and Vitest as the test runners underneath everything. Chapters 3–5 build up React Testing Library, the tool this course spends the most time on, for component-level testing. Chapter 6 covers mocking dependencies with MSW (Mock Service Worker). Chapter 7 steps back to compare Vue Test Utils, Angular's TestBed, and Svelte Testing Library — since this site already has complete courses for all three frameworks.

Coding Challenges

Chapter 1 established why and what to test. This chapter is the how — the test runner mechanics that every later chapter builds on, kept deliberately DOM-free for now so the focus stays on the runner itself.

Anatomy of a Test File

describe groups related tests under a label. it (or test — the two are interchangeable) defines one individual test case. expect(...) wraps a value so a matcher like .toBe(...) can assert something about it.

Common Matchers

The toBe vs. toEqual distinction trips up almost everyone early on — covered concretely below.

Setup and Teardown

beforeEach/afterEach run before or after every single test; beforeAll/afterAll run once for the whole describe block. Resetting shared state before each test keeps tests isolated — one test's leftover state should never affect another, a concern that becomes far more important once mocking enters the picture.

Basic Mocking with jest.fn() / vi.fn()

A quick preview of Chapter 6's deeper territory — here, just the raw mechanic: a mock function records how it was called, without needing any real implementation behind it.

Vitest: Jest's Vite-Native Sibling

Vitest was built specifically for Vite-based projects — faster, native ESM, no separate Babel/webpack transform step — and deliberately copied Jest's API almost one-to-one. describe, it, and expect work identically; the one real naming difference in the basics is jest.fn() becoming vi.fn(). This course uses Jest's naming by convention (it remains the more common baseline), but everything transfers directly to Vitest with that single substitution.

Coding Challenges

Chapter 1 named the fix; Chapter 2 built the raw test-runner mechanics. This chapter introduces the actual tool built around that philosophy — React Testing Library (RTL) — and the philosophy itself, before any real component interaction begins in Chapter 4.

The Guiding Principle

Testing Library's own tagline, from creator Kent C. Dodds, states the whole philosophy in one line: "The more your tests resemble the way your software is used, the more confidence they can give you." Concretely, that means testing through the same interface a real user has — what's visible on screen, what can be clicked or typed into — never through a component's internal React state, props, or methods.

render(): Mounting a Component Into a Test DOM

render(...) mounts a component into a lightweight, jsdom-based test DOM and returns the screen object, used to query it. Older tools like Enzyme — React's previous, now-deprecated testing library, still referenced in a lot of older tutorials — deliberately exposed internals like .state() and .instance(). RTL deliberately does not provide any way to reach into a component's internals at all. That's a design choice, not a missing feature.

Querying by Role, Text, and Label

Every one of these queries something a real user (or assistive technology) actually perceives — an ARIA role, visible text, a form label — rather than a CSS class or internal prop, directly resolving Chapter 1's CSS-class gotcha. This connects concretely to web-accessibility1's ARIA material: writing accessible markup in the first place is what makes a component queryable by role or label at all. Accessibility and testability reinforce each other by construction, not by coincidence.

The getBy / queryBy / findBy Trio

The Query Priority Guide

Testing Library's own documented, recommended order — not just this course's opinion:

1. getByRole — first choice; matches how assistive technology and most users actually perceive an element
2. getByLabelText / getByPlaceholderText / getByText — strong alternatives when a role query doesn't fit
3. getByTestId — an explicit last resort, an escape hatch for when nothing else works, not a default habit

Coding Challenges

Chapter 3 established the philosophy and the query system. This chapter puts both into practice — rendering real components, simulating genuine user interaction, and asserting on what actually changes on screen.

Rendering and Asserting on Output

Firing Events: fireEvent vs. userEvent

fireEvent dispatches a single, low-level DOM event directly. userEvent (from @testing-library/user-event) simulates the full, realistic sequence of events a real browser fires for that interaction — typing one character involves keydown, keypress, input, and keyup in order; a click involves pointer and focus events too. Testing Library's own current recommendation: prefer userEvent whenever possible, since it more closely resembles real usage — directly extending Chapter 3's guiding principle.

Asserting on Conditional Rendering

Combining Chapter 3's query trio with real interaction — confirming something is absent, triggering a change, then confirming it appears:

Snapshot Testing: What It Is

expect(container).toMatchSnapshot() captures the entire rendered output into a stored file — future runs diff against it and flag any difference. The appeal is real: fast to write, catches unintended changes. The real problem is just as real: a snapshot captures everything, including implementation details Chapter 1 and 3 have been warning about all along. A tiny, intentional style tweak can produce a giant diff that gets rubber-stamped without real review — a well-known failure mode called "snapshot blindness."

When Snapshots Are (and Aren't) a Good Fit

Coding Challenges

Chapter 4 tested components as black boxes through their rendered output. This chapter covers two more specific situations: testing a custom hook in isolation — which has no JSX of its own at all — and testing components whose correctness depends on useState/useEffect timing, including controlled forms and asynchronous updates.

Testing Custom Hooks with renderHook

A custom hook like useCounter isn't a component — render() and screen don't apply. renderHook mounts a hook inside a minimal, invisible test component behind the scenes, returning a result object whose .current holds the hook's live return value:

act(...) tells React "a state update just happened here — flush it and re-render before continuing." Without it, an assertion immediately after calling an updater function can read a stale value from before React has actually processed the update.

Testing Components That Use useState

A controlled input's displayed value depends on component state that changes as the user types — combining Chapter 4's userEvent.type with a query that reads the input's current value:

Testing useEffect Timing

A component that fetches data in useEffect doesn't show its result synchronously — this is exactly where Chapter 3's findBy and the more general waitFor matter. findBy* is a convenience wrapper built around one query; waitFor(callback) is general-purpose — it re-runs an arbitrary assertion callback until it passes or times out, useful when a check can't be expressed as a single query.

Controlled Forms End to End

Combining everything: typing into multiple controlled inputs, submitting, and confirming an async result:

Coding Challenges

Chapter 5 tested components that fetch data, using findBy/waitFor to wait for it — but never addressed where that data actually came from during the test. This chapter closes that gap.

The Problem With Real Network Calls in Tests

A real network call in a test is slow, depends on an external service actually being up, and makes it hard to deliberately trigger error cases (a 500 response, a timeout) on demand. Unit and component tests are supposed to be fast and deterministic — directly the speed argument behind Chapter 1's testing pyramid — and a real network dependency violates both.

Mocking fetch/axios Directly

This works, but couples the test tightly to how the request is made (specifically fetch, or specifically axios) rather than what the request and response actually are. Swapping the underlying HTTP client later means rewriting every test that mocked it this way.

Mock Service Worker (MSW): The Modern Preferred Approach

MSW intercepts requests at the network level rather than mocking the fetch/axios function itself — the component's real request code runs completely unmodified; only the server's response is faked. This is genuinely more realistic, a direct extension of Chapter 3's guiding principle applied to network behavior, and resilient to swapping HTTP libraries later.

The beforeAll/afterAll lifecycle is Chapter 2's setup/teardown hooks, now managing a mock server's lifetime.

Simulating Error Responses

MSW makes deliberately testing error states trivial — override a handler for one test only:

Mocking Timers

Components using setTimeout/setInterval — a debounced search box, a toast that auto-dismisses — would otherwise force tests to actually wait real time, or behave flakily. jest.useFakeTimers() lets a test advance time instantly:

Mocking Context Providers

A component consuming React Context (e.g. useAuth()) needs that context available to render sensibly — wrapping it in a lightweight, test-only provider with preset fake values avoids needing a real login flow or real backend:

A reusable helper like this is worth introducing now — Chapters 8–9's more realistic feature tests will lean on it directly.

Coding Challenges

Chapters 2–6 built deep, React-specific fluency with Testing Library. This chapter steps back: the same underlying philosophy — test like a user, not the implementation — shows up in Vue, Angular, and Svelte's own testing tools too, at varying distances from RTL's exact API. This site already has complete courses for all three frameworks; this chapter connects to them directly rather than re-teaching them.

Vue Test Utils

Vue's own official testing library, conceptually the closest of the three to RTL — mount() renders a component into a test environment, returning a wrapper to query. Vue's own community has increasingly adopted @testing-library/vue, a Testing-Library-flavored wrapper providing the exact same getByRole/getByText query style used throughout this course:

Angular's TestBed

A fundamentally more ceremonial approach — Angular's dependency-injection-driven architecture means testing a component typically requires configuring a TestBed module (declaring the component, its dependencies, mock services) before it can even be instantiated:

This is noticeably more setup than RTL's single render() call — a direct consequence of Angular's DI-heavy architecture, not a difference in testing philosophy. @testing-library/angular exists specifically to wrap this ceremony behind a more familiar render() + screen API.

Svelte Testing Library

@testing-library/svelte is the closest of all three to React's version — Svelte's compile-time component model needs neither Angular's DI ceremony nor Vue's separate wrapper API. render(), screen, and fireEvent/userEvent work almost identically to every example in Chapters 3–6.

The Pattern Across All Four

React's virtual DOM, Vue's reactive templates, Angular's DI-plus-zone-based change detection, and Svelte's compile-time approach are genuinely different component models under the hood. Despite that, every major framework's testing ecosystem has converged, to varying degrees, on the same Testing-Library-popularized idea: query by role/text/label, fire realistic events, assert on user-visible outcomes. Chapter 3's philosophy isn't a React quirk — it's closer to an industry-wide norm for component-based UI testing.

Coding Challenges

Chapter 1's testing pyramid named "integration tests" as its middle layer, but Chapters 2–7 have stayed mostly at the component level. This chapter finally writes a genuine integration test, then turns to two different topics: what code coverage actually measures (and where it misleads), and the accessibility-testing tool that closes the loop back to web-accessibility1.

From Component Tests to Integration Tests

A component test renders one component, often with mocked props/children. An integration test renders a parent alongside its real children, exercising how they actually communicate — using Chapter 6's MSW to fake the underlying API, since the point is exercising the real component wiring, not a real network:

Neither SearchForm nor SearchResults is mocked — the test proves they genuinely work together, not just individually.

Code Coverage: What It Measures

jest --coverage reports what percentage of lines, branches, functions, and statements were executed during the test run — useful as a rough signal for finding obviously untested code, not as proof of correctness.

Why 100% Coverage Can Be Misleading

A line being executed says nothing about whether it was actually asserted on correctly. Consider a genuinely hollow test:

This test contributes real coverage percentage while catching precisely zero bugs. 100% coverage is neither necessary nor sufficient for a genuinely well-tested codebase — coverage finds obviously neglected code (0% on an entire file is a real red flag), it doesn't validate that the tests which do exist are meaningful.

Setting Sensible Coverage Thresholds

Jest's coverageThreshold config option fails the test run if coverage drops below a set percentage — a practical floor (commonly 70–80%) that catches obviously-neglected code, not a target chased for its own sake. A team mandate of "100% coverage or the PR is blocked" actively incentivizes exactly the hollow test shown above.

Accessibility Testing with jest-axe

jest-axe runs automated accessibility checks — missing labels, invalid ARIA usage, and more — against rendered output, closing the loop directly to web-accessibility1:

Automated checks like axe catch only a subset of real accessibility problems — structural/markup issues, not things like whether an error message makes logical sense in the order a screen reader announces it. Manual testing, exactly as web-accessibility1 covers, is still necessary — axe is a floor, not a substitute.

Coding Challenges

One feature, one complete test suite, every chapter's tool making an appearance: rendering, real user interaction, async mocking, conditional rendering, and an accessibility check.

The Feature Under Test

LoginForm: an email field and a password field, both required. Submitting calls POST /api/login. While the request is pending, the button reads "Signing in...". A failed login (401) shows an error message. A successful login shows a welcome message.

Setting Up MSW for the Capstone

The Full Test Suite

What This Capstone Demonstrates

Chapter 2's runner mechanics (describe/it/expect) sit underneath every single one of these, and Chapter 7's point stands too — this exact same suite, translated to @testing-library/vue or @testing-library/svelte, would look nearly identical.

Coding Challenges