The environment is already alive: Vitest finds the files, jsdom provides a DOM, and the jest-dom matchers are registered. It's time to write real tests, and this lesson does it deliberately outside React. There isn't a single render anywhere in this text. The reason is twofold: first, because the runner's tools — describe, the hooks, the assertions, the test doubles, the fake timers — are much easier to understand without the noise of a component tree; and second, because the most cost-effective part of CicloUrbano is precisely the part that doesn't need React. validateBooking encodes every business rule around bookings. The bookingsSlice reducer encodes the activa → confirmada / cancelada lifecycle. The selectors derive the visible catalogue. All three are pure functions, and testing a pure function means calling it and comparing. That's what was promised back in 05-05 and 07-04, and this lesson cashes it in.

The title says "with Jest," and there's a reason to honor it: Jest is the ecosystem's mental model. Everything you learn here gets written with Vitest, which is what fits a Vite project, but its API is the same, so it applies exactly as well to the thousands of projects that use Jest. We'll start by making that equivalence clear.

1. What a test runner is and what it does for you
2. Jest and Vitest: the same model, two implementations
3. Configuring Jest in a project that doesn't use Vite
4. Anatomy of a test file: describe, test, and the hooks
5. Assertions: the matcher catalogue
6. toBe vs. toEqual: the difference that causes the most bugs
7. The validateBooking suite, rule by rule
8. Edge cases and test.each
9. Testing the bookingsSlice reducer as a pure function
10. Testing the selectors
11. Test doubles: spies, stubs, and mocks
12. vi.fn(): checking that a callback was called
13. vi.spyOn and vi.mock: substituting without breaking things
14. Controlling time: vi.useFakeTimers
15. Running, filtering, and reading coverage

A test runner is a program that automates everything around a test. Without one, you'd have to hand-write the loop that calls each function, the try/catch that catches errors, and the console.log that summarizes the result. With one, you write only the part that adds value.

What a modern runner does, in execution order:

That "report" column is the one you notice most while debugging. When an assertion on objects fails, a good runner doesn't say "they're not equal": it says which field differs.

Jest was born at Facebook and became the de facto standard for testing in JavaScript: for years, "testing in React" and "testing with Jest" were the same sentence. Create React App shipped it preconfigured, and most of the documentation, Stack Overflow answers, and legacy code you'll run into is written against its API.

Vitest came later, for projects built with Vite, and made a very deliberate design decision: replicate Jest's API. It's not a similar dialect; it's the same API, with the same behavior, so migrating costs almost nothing and everything the ecosystem already knows keeps working.

Why CicloUrbano uses Vitest and not Jest:

• It shares Vite's configuration. The aliases, plugins, environment variables, and module resolution are already defined in vite.config.js. With Jest, all of it would need to be duplicated and kept in sync.
• It understands ES modules natively. The whole project uses import/export. Jest relies on CommonJS and needs a transform or experimental flags for ES modules.
• It transforms with esbuild. Startup in tens of milliseconds instead of seconds, and near-instant watch mode.
• There's no second build pipeline. What gets tested is transformed the same way as what runs in development. That eliminates a whole family of "works in the app but not in the tests" bugs.

The real differences boil down to three things: the vi prefix instead of jest, where the configuration lives, and how the code gets transformed. 95% of the content of a test file is identical. In fact, with globals: true in the configuration, a test file written for Jest will usually run in Vitest without touching a single line.

In this project, vi is always used. When you come across code with jest.fn(), you'll know it's exactly the same thing.

This is the recipe for when you end up on a project with Webpack, legacy Create React App, or no modern bundler. It isn't used in CicloUrbano, but it's worth being able to read.

Notice the extra work that shows up here and that simply doesn't exist in Vitest: a moduleNameMapper for CSS and images, a Babel configuration, a separate package for the DOM environment, and duplicated aliases. That's exactly what you save by sharing Vite's configuration, and it's the practical argument from the previous section.

With globals: true in the configuration, that first import line is optional. This course will omit it to avoid repeating it in every example.

The execution order is the one marked by the numbers in the example, and it has its own logic: the befores go from outside in, and the afters go from inside out, like a stack. That is: outer beforeAll → inner beforeAll → outer beforeEach → inner beforeEach → the test → inner afterEach → outer afterEach → inner afterAll → outer afterAll.

Practical consequences:

• Prefer beforeEach to beforeAll. beforeAll creates shared state, which is the number-one cause of tests that only fail when the full suite runs (the 8.3 problem from the previous lesson). Only use it for something that's expensive and read-only.
• Code inside a describe but outside a hook runs when the file loads, not before each test. This is a classic bug:

• Hooks can be asynchronous. If they return a promise, the runner waits for it. This gets put to use in 09-04 to start MSW's server.

An assertion is expect(actualValue).matcher(expectedValue). If the check fails, an error is thrown with the diff, and the test is marked red.

Any matcher can be inverted by prefixing .not:

A warning about .not, because it's a recurring trap: a negative assertion proves less than it looks like. expect(errors).not.toHaveProperty('hours') passes whether the validation is correct or validateBooking returns {} because it's entirely broken. Whenever you can, pair a negative assertion with a positive one:

That single assertion says at once that there is a date error and that there's no other one, which is exactly what you want to state.

• toBe uses Object.is, comparison by identity. For primitives — strings, numbers, booleans — identity and content coincide, so expect('activa').toBe('activa') works. For objects and arrays, it compares references.
• toEqual walks the structure and compares key by key, recursively.

This distinction isn't an academic detail: it's exactly the same identity comparison that governs memo and useMemo in Module 8, and the one that makes a selector returning a new array re-render the component in 07-05. The mnemonic rule: toBe for primitives, toEqual for objects and arrays.

And a difference between toEqual and toStrictEqual worth keeping in mind:

toEqual ignores properties with the value undefined; toStrictEqual doesn't, and it also checks that both objects are the same class. In CicloUrbano, toEqual is the usual choice, because a missing optional field and an optional field set to undefined mean the same thing to the application. Use toStrictEqual when the absence of a key is meaningful.

Here's the lesson's central case. Recall the function you practiced writing in 03-05: it receives data and the catalogue of bikes, and returns an object with one message per field with an error, or {} if everything is valid. Four rules: bike required, existing, and available; date required, valid, and not earlier than now; hours an integer between 1 and 24; terms accepted.

Two design decisions that apply to any validation suite:

• The validData(changes) factory. Without it, every test would repeat all four fields and the reader would have to visually diff them to figure out what's being tested. With it, validData({ hours: 25 }) says on its own what's being checked. Also, if the form gains a fifth field tomorrow, there's only one place to change.
• The frozen clock in beforeEach. The date rule compares against Date.now(). If the test used the real clock, the date '2026-05-04T09:00' would be valid today and invalid a year from now: a test with an expiration date, which is a textbook flaky test. By freezing the system to 2026-05-04T08:00, the test gives the same result a decade from now.

Notice the deliberate mix of matchers, because each one says something different:

• toEqual({ bicicletaId: '…' }) in the first one states that that's the only error. It's the strongest assertion, and the one that would catch a regression that also broke the date check.
• toBe('Electric Pro is not available right now.') checks the literal message, including the model interpolation. That's correct here because the user reads that text, and it's part of the behavior.
• toContain('is not available') is deliberately looser: it checks the rule without tying itself to the exact wording. Use it when the text might change for editorial reasons without the behavior changing.

That last test is worth more than it looks. It verifies an explicit design decision from 03-05: validation doesn't stop at the first error, because a form that shows errors one at a time forces the user into four attempts. If someone refactors validateBooking with early returns, this test catches it.

Edge cases are the values sitting right at the boundary of a rule, and that's where most real bugs live. For hours, the rule is "an integer between 1 and 24." The boundaries are 0/1 and 24/25.

Writing eight nearly identical tests is noise. test.each takes a table and generates one test per row:

How it works:

• The table is an array of arrays. Each row gets destructured into the test function's parameters.
• The name accepts printf-style placeholders: %p prints the value as-is (useful for telling '' apart from 'two'), %s converts it to a string, %i to an integer. The report shows nine tests with distinct names, so a failure points to the exact row.
• There's also a tagged-template variant, more readable when there are many columns:

Look at the 2.5 row. Without it, this alternative implementation of the rule would pass every other test:

With 0, 1, 24, and 25 the suite would be green, and yet the user could book for two and a half hours — something the price-per-hour and the station system don't account for. That's the case for edge cases in one sentence: tests for "normal" values confirm what you already knew; tests for the boundaries find what you didn't.

The list of boundaries worth exercising every time: zero, the minimum value, the maximum, the maximum plus one, a negative number, a decimal when an integer is expected, the empty string, null, undefined, and the empty collection.

This is where we close what was left pending in 05-05 and promised again in 07-04: a reducer is a pure function (state, action) => newState, so testing it means calling it and comparing. No React, no store, no component, no Provider needed.

Recall the shape of the state: { entities, ids, loadState, error, submitState }, normalized.

That second test uses toBe on purpose, and it's a good example of when identity is observable behavior: if the reducer returned a copy for every unrelated action, every useSelector subscribed to bookings would re-render on any action in the app. It's the problem from 07-05 turned into a test.

Three things these tests verify that you can't verify by looking at the screen:

1. The exact shape of the state after the action, including submitState and error, which only show up indirectly in the UI.
2. That prepare generates the identifier in the agreed format, res- plus eight characters. That's why crypto.randomUUID gets spied on: without pinning it, the identifier would differ on every run and there'd be nothing to compare against.
3. That there's no mutation. Even if you write state.ids.push(...) inside the reducer, Immer — which Redux Toolkit includes — produces a copy. This test confirms it, and it would catch the day someone pulls that logic out of createSlice and the mutation becomes real.

The reducer's most valuable rules are its guards, because they're invisible and hard to trigger by hand:

That last test is exactly the kind of check that justifies the whole module: reproducing a double cancellation by hand, with the right timing, is tedious and unreliable; in code it's six lines, and it runs in two milliseconds, forever.

A selector is just as pure: (state) => derivedValue. The only quirk is that the project's selectors receive the global state, not the slice's own slice of it, so it has to be built in the shape defined by store.js: { bookings, catalogue, session }.

A memoized selector has one extra property that does deserve testing, because it's the whole reason it exists: returning the same reference if the inputs don't change. It's what prevents the re-renders from 07-05, and it's exactly what someone would break by swapping it for a plain function.

An important warning: since createSelector's memoization only keeps one result, interleaving calls with different states invalidates the cache each time. If you write this test and it fails unexpectedly, check that there isn't a call with a different state in between.

A test double is any object that substitutes for a real dependency during a test, the same way a stunt double substitutes for an actor in a dangerous scene. The names get used loosely day to day, but the distinctions are useful:

The rule that governs all of this, and that will come back in 09-04 with MSW:

Mock as little as possible. Every test double is a copy of reality that can drift out of sync with it. A test full of mocks ends up testing the mocks.

vi.fn() creates a mock function that does nothing, returns undefined, and records every call. It's the basic tool for verifying the project's callbacks: CicloUrbano's onX convention — onBook, onTypeChange, onCreateBooking — is precisely what gets checked with it.

About argument assertions: when the argument is an object, toHaveBeenCalledWith compares structurally, not by identity. And if you only care about part of the object, there are asymmetric matchers:

This last one is the right approach for an identifier generated with crypto.randomUUID(): checking the format, not the value, avoids having to spy on the crypto function.

vi.spyOn(object, 'method') replaces that method with a mock function that, by default, still calls the original. The most common case in React tests is silencing console.error, and it'll come up again in 09-04 when testing ErrorBoundary.

vi.restoreAllMocks() in the afterEach is not optional. If you don't restore console.error, every later test in the same process goes silent, including React's legitimate warnings. It can be automated in the global configuration:

When what needs substituting is an entire module — because it makes requests, writes to an external service, or depends on the environment — you use vi.mock:

Three details that cause errors if ignored:

1. vi.mock gets hoisted to the top of the file. Even if you write it after the imports, it runs before them. That's why the factory can't close over external variables: the vi.fn()s get declared directly inside it. If you need a reference outside, use vi.hoisted.
2. The mocked module replaces every one of its exports. If monitoring.js exported ten functions and you only declare two in the factory, the other eight become undefined. To keep the rest, combine it with importActual:

3. vi.mock is the biggest hammer in the box. It replaces the real module with a copy that doesn't evolve with it: if reportError changes its signature tomorrow, the test keeps passing with the old signature. Hence the rule from section 11. In order of preference: pass the dependency as a parameter > vi.spyOn on a specific method > vi.mock the entire module. And for the network, none of the three: MSW (09-04).

Time is the biggest source of slow, flaky tests. vi.useFakeTimers() replaces setTimeout, setInterval, clearTimeout, Date, and performance.now with controlled implementations: the clock only moves forward when you tell it to.

Let's test the mechanism behind useDebounce at the function level, without React. The hook wraps a setTimeout that gets cancelled during cleanup; this is the logic, and it's what needs verifying:

The third test is the one that justifies all of useDebounce from Module 5 and all the search-optimization work from Module 8, and it's the one that would be almost impossible to verify by hand: reproducibly typing six letters in under 400ms isn't something fingers can do. With fake timers, it's deterministic and takes one millisecond.

With fake timers, if you forget to advance the clock, the test waits forever. The symptom is a timed-out test. Testing useDebounce inside React, with renderHook, is covered in 09-04, because it requires combining fake timers with act.

Vitest keeps listening, and when you save a file it reruns only the tests affected by that change, following the import graph. Saving validateBooking.js reruns validateBooking.test.js and BookingForm.test.jsx, but not the 40 booking tests. In watch mode there are useful keys:

About test.only: it's extremely useful while debugging and catastrophic if you forget it's there, because it silently disables the rest of the file and the suite stays green. The safeguard is a lint rule (vitest/no-focused-tests or jest/no-focused-tests) that turns it into an error. Turn it on.

test.todo is the right way to note what's missing: it shows up in the report as pending, it doesn't fail, and it doesn't lie about coverage the way a permanent test.skip would.

How to read this without falling into the trap from section 8.1 of the previous lesson:

• The most informative column is % Branch. 100% statements with 50% branches means every line runs, but only one of the two paths of each if. In monitoring.js, that 50% points to the production branch never being exercised.
• Uncovered Line #s is the to-do list. Lines 47 and 63 of bookingsSlice.js are, very likely, two guards (if (!booking) return;) that haven't been triggered yet. They deserve a test: they're business rules.
• The 0% for BookingForm.jsx is correct today, because components get tested in 09-03. It's not an alarm: it's a known, planned gap.
• The HTML report at coverage/index.html paints the source code with uncovered lines in red and partial branches in yellow. It's far more useful than the table for deciding what to test.

And the ever-present rule: the goal isn't the number. The goal is for the red lines in the business logic to stop being red.

• Using toBe with objects and arrays. The number-one beginner mistake. expect({ a: 1 }).toBe({ a: 1 }) always fails. Rule: primitives with toBe, structures with toEqual, and deliberate identity with toBe only when the reference is the behavior under test (memoization, a reducer that must not copy).
• Sharing state between tests with beforeAll or a mutable constant. Produces tests that pass alone and fail in the suite, or the other way around. beforeEach rebuilds; beforeAll only for what's expensive and immutable.
• Forgetting vi.useRealTimers() in the afterEach. Fake timers stay active and contaminate the rest of the file; a later test that waits for real hangs until it times out. Same goes for vi.restoreAllMocks() and console.error.
• Leaving a test.only in the code. Silently disables the rest of the file, and the suite stays green because it's empty. Turn on the lint rule that forbids it.
• Testing the reducer's implementation instead of its result. Don't check that state.ids.push got called; check that the returned state contains the new identifier. It's the principle from 09-01, applied to Redux.
• Mocking too much. A vi.mock of a module that belongs to the project itself is usually a sign of coupling. Before mocking, ask whether the dependency could come in as a parameter: validateBooking(data, bikes) receives the catalogue precisely for that reason, and that's why it's tested without any double.
• Testing a pure function with more setup than necessary. If testing the reducer means building a full Redux store, you've lost the advantage: call it directly.
• Tip: write the failing test first. Even if you don't practice test-driven development, confirming the test fails before writing the code is the only way to know the test checks something. A test that's never been red might be checking nothing at all.
• Tip: when you fix a bug, write the test that reproduces it first. It confirms you've understood it and keeps it from coming back. It's the best moment to write a test, because you already have the concrete case in hand.
• Tip: if a test needs more than ten lines of setup, the code under test has too many dependencies. Difficulty testing something is a design signal, not an annoyance from the runner.

Exercise 1. Write the suite for src/utils/classNames.js, the utility that composes class names while ignoring falsy values:

Cover at least: several names, a false value mixed in (the condition && styles.active case), undefined and null, calling with no arguments, and calling with a single name. Use test.each where it makes sense, and justify why the result gets compared with toBe rather than toEqual.

Exercise 2. The team adds a new rule to validateBooking: a bike of type carga cannot be booked for more than 8 hours. Write the tests before implementing it — including the edge cases — and then the minimal implementation that makes them pass. State which test in the existing suite might fail because of the change, and why.

Exercise 3. This test for bookingsSlice always passes, even if the reducer is broken. Explain why, and rewrite it so it verifies what it's meant to.

Solution 1.

It's compared with toBe because the result is a string, i.e., a primitive: identity and content coincide, and toBe also gives a clearer error message with the text diff. toEqual would work the same, but using the more specific matcher documents the type of the returned value.

Notice the last row: cx() with no arguments returns '', not undefined or a space. It's a real edge case, because that value ends up in className, and an undefined there would render the attribute literally in some scenarios.

Solution 2. First, the tests:

The minimal implementation, added after the general maximum check:

Which existing test might fail: none of the ones using bici-001, since it's urban. But any future test that booked bici-003 for more than 8 hours expecting the generic 24-hour message would fail. And there's a design detail the suite forces you to resolve: the new check must not override the availability error, hence the !errors.hours, and hence the test case uses an available cargo bike. Writing the test first is what surfaced that decision before implementing it.

Solution 3. Why it always passes: all three assertions are tautological.

• expect(result).toBeTruthy() passes for any object, even the untouched state.
• expect(result.entities).toBeDefined() passes as long as the reducer returns anything with that key.
• Object.keys(result.entities)).toHaveLength(1) counts the entities, which don't change on cancellation: cancelling marks, it doesn't remove. In other words, that assertion would pass just the same if the reducer did absolutely nothing.

None of the three looks at status, which is the only thing the action should change. On top of that, the name ("cancellation works") doesn't say what behavior is being verified.

Rewritten:

Now each test asserts one concrete, verifiable behavior, and any of them would go red if the reducer stopped doing its job. The second one, on top of that, documents a design decision — cancelling doesn't delete — that would otherwise live only in the head of whoever wrote it.

This lesson built the module's foundation without touching React, and showed why that part is the most cost-effective: validateBooking, the bookingsSlice reducer, and the selectors concentrate every one of CicloUrbano's business rules, and testing them means calling them and comparing.

The essentials. A test runner discovers, transforms, isolates, parallelizes, reports, watches, and measures. Jest is the ecosystem's mental model and Vitest implements the same API; the only real differences are the vi prefix instead of jest, where the configuration lives, and how the code gets transformed, so what you learned here works for both — and you have the recipe for jest.config.js with its moduleNameMapper, its Babel setup, and its jest-environment-jsdom, for the day you land on a project without Vite. The anatomy of a file is describe, test/it, and four hooks whose order is a stack: the befores from outside in, the afters from inside out; and the rule that follows from that is preferring beforeEach to beforeAll, because shared state is the number-one cause of tests that only fail in the full suite.

From the catalogue of matchers, the distinction that causes the most bugs is toBe vs. toEqual: identity against structure, the same comparison that governs memo in Module 8 and the selectors in Module 7. Primitives with toBe, objects with toEqual, toStrictEqual when the absence of a key is meaningful, and .not always paired with a positive assertion to anchor it — because toEqual({ startDate: '…' }) states at once that there is that error and that there's no other one.

The validateBooking suite established two reusable patterns: the validData(changes) factory, which makes it obvious which field each test is breaking, and the frozen clock with vi.setSystemTime, without which the date rule would expire. And test.each turned nine hours edge cases into a readable table, with the underlying lesson: the decimal case 2.5 is the one that catches an implementation that 0, 1, 24, and 25 would let through. Tests for normal values confirm what you already knew; tests for the boundaries find what you didn't.

The reducer closed out what was promised in 05-05 and 07-04. It's tested by calling it directly — no store, no Provider, no components — chaining the state from one call to the next to walk the activa → confirmada / cancelada cycle, and verifying what the screen doesn't show: the business guards, the absence of mutation, and — with toBe — that it returns the same reference for unrelated actions, which is what keeps the whole app from re-rendering. Selectors are tested the same way, building the global state in the shape of store.js, and the ones memoized with createSelector have their own necessary test: that they return the same reference if the inputs don't change.

About test doubles, you now tell apart spy, stub, mock, and fake, and you've mastered the three tools: vi.fn() to verify the project's onX callbacks with toHaveBeenCalledWith and asymmetric matchers like expect.objectContaining; vi.spyOn to wrap console.error without polluting the output, always with its restoreAllMocks; and vi.mock to substitute an entire module, with its three traps — hoisting, wholesale replacement of the exports, and silently drifting away from the real module. Hence the hierarchy: parameter > spyOn > mock, and for the network, none of the three. Fake timers turned into something deterministic what was impossible to reproduce by hand: six keystrokes in 500ms that must produce a single call with 'urbana'. And you know how to run in watch mode, filter with test.only/test.skip/test.todo — with the lint rule that prevents forgetting an only — and read a coverage report by looking at the branches column and the uncovered lines in the business logic.

What remains is the visible half. The rules are tested, but nobody has yet checked that the user sees the message "The maximum booking is 24 hours" next to the right field, or that the "Book" button is disabled for a bike in maintenance, or that clicking a filter notifies the parent with the chosen type. That's the territory of the next lesson, and where the testing trophy puts its greatest weight: real components, mounted in jsdom, queried the way a person would query them — by role, by label, by accessible text — and interacted with via userEvent. There you'll see why all the accessibility work from Module 3 was, without saying so, the preparation for this. The next lesson is Testing Components with React Testing Library.