Block 3 schließt mit einem Thema, das perfekt zu allem bisher Gelernten passt: Tests. Für den Rezept-Planer entsteht in diesem Kapitel ein tests/-Ordner mit echten, automatisierten Tests für die Validierungsfunktion aus dem letzten Kapitel und die Suchlogik aus Kapitel 12.

Warum Tests ein besonders guter Anwendungsfall sind

Tests profitieren von genau den Eigenschaften, die Claude Code gut beherrscht: Sie folgen wiederkehrenden Mustern, lassen sich unmittelbar ausführen und liefern ein klares Ja/Nein-Ergebnis. Das macht Testen zu einem Bereich, in dem du sehr schnell sehen kannst, ob eine Änderung tatsächlich funktioniert - und in dem Claude Code seine eigene Arbeit direkt selbst überprüfen kann, statt dass du es manuell tun musst.

Tests für die Validierung anfordern

> Schreib Tests für validateRecipe() aus src/recipes.js, mit dem eingebauten Node-Testrunner (node --test). Deck dabei ab: gueltiges Rezept, fehlender Titel, leerer Titel, fehlende Zutatenliste, leere Zutatenliste.

Dieser Prompt zählt bewusst die konkreten Testfälle auf, statt nur "schreib Tests" zu sagen - genau wie bei den Feature- und Bug-Prompts aus den vorherigen Kapiteln. Ein typisches Ergebnis:

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

test("gueltiges Rezept wirft keinen Fehler", () => {
  assert.doesNotThrow(() =>
    validateRecipe({ title: "Pasta", ingredients: ["Nudeln", "Tomaten"] })
  );
});

test("fehlender Titel wirft einen Fehler", () => {
  assert.throws(() => validateRecipe({ ingredients: ["Nudeln"] }));
});

test("leere Zutatenliste wirft einen Fehler", () => {
  assert.throws(() =>
    validateRecipe({ title: "Pasta", ingredients: [] })
  );
});

Die Tests lassen sich direkt ausführen - und genau das sollte Claude Code nach dem Schreiben auch selbst tun, um zu bestätigen, dass sie tatsächlich grün sind:

npm test

Den Bug aus Kapitel 13 als Test absichern

Ein besonders wertvolles Muster: Nachdem in Kapitel 13 der Leerzeichen-Bug in der Zutatensuche behoben wurde, lohnt sich ein Test, der genau diesen Fall dauerhaft absichert - so kann derselbe Fehler nicht unbemerkt wieder zurückkehren, wenn später jemand (oder Claude Code selbst) den Code an dieser Stelle erneut ändert.

> Schreib einen Regressionstest für den Leerzeichen-Bug aus der Zutatensuche: eine Zutat mit führendem Leerzeichen muss trotzdem gefunden werden.

Test-getriebenes Arbeiten in kleinen Dosen

Für neue, kleinere Funktionen lässt sich das Vorgehen auch umdrehen: erst Claude Code bitten, einen fehlschlagenden Test für ein noch nicht existierendes Verhalten zu schreiben, dann erst die passende Implementierung dazu - ein einfacher Einstieg in test-getriebene Entwicklung, ohne dass du dich mit der vollen Theorie dahinter beschäftigen musst.

Damit ist das Fundament des Rezept-Planers vollständig: Struktur, ein echtes Feature, ein behobener Bug, ein durchgeführtes Code-Review und eine Testsuite. Block 4 baut darauf auf und zeigt fortgeschrittene Funktionen von Claude Code - beginnend mit den eingebauten Slash-Commands.