Block 3 closes with a topic that fits perfectly with everything learned so far: tests. In this chapter, the recipe planner gets a tests/ folder with real, automated tests for the validation function from the last chapter and the search logic from chapter 12.

Why tests are a particularly good use case

Tests benefit from exactly the qualities Claude Code handles well: they follow recurring patterns, can be run immediately, and give a clear yes/no result. That makes testing an area where you can very quickly see whether a change actually works - and where Claude Code can verify its own work directly, instead of you having to do it manually.

Requesting tests for the validation

> Write tests for validateRecipe() from src/recipes.js, using the built-in Node test runner (node --test). Cover: valid recipe, missing title, empty title, missing ingredient list, empty ingredient list.

This prompt deliberately lists the concrete test cases instead of just saying "write tests" - just like the feature and bug prompts from the previous chapters. A typical result:

import { test } from "node:test";
import assert from "node:assert/strict";
import { validateRecipe } from "../src/recipes.js";

test("a valid recipe does not throw", () => {
  assert.doesNotThrow(() =>
    validateRecipe({ title: "Pasta", ingredients: ["noodles", "tomatoes"] })
  );
});

test("a missing title throws", () => {
  assert.throws(() => validateRecipe({ ingredients: ["noodles"] }));
});

test("an empty ingredient list throws", () => {
  assert.throws(() =>
    validateRecipe({ title: "Pasta", ingredients: [] })
  );
});

The tests can be run directly - and that's exactly what Claude Code should do itself after writing them, to confirm they actually pass:

npm test

Locking in the chapter 13 bug as a test

A particularly valuable pattern: after the whitespace bug in the ingredient search was fixed in chapter 13, it's worth writing a test that permanently guards exactly that case - that way the same bug can't quietly come back if someone (or Claude Code itself) changes this code again later.

> Write a regression test for the whitespace bug in the ingredient search: an ingredient with a leading space must still be found.

Test-driven work in small doses

For new, smaller functions, the approach can also be flipped: first ask Claude Code to write a failing test for behaviour that doesn't exist yet, then write the matching implementation afterwards - a simple way into test-driven development, without needing to dig into the full theory behind it.

That completes the foundation of the recipe planner: structure, a real feature, a fixed bug, a completed code review, and a test suite. Block 4 builds on this and covers Claude Code's more advanced features - starting with the built-in slash commands.