Test-Driven Development (TDD)

Test-Driven Development mit Claude Code

0:00 Test-Driven Development hat einen zwiespältigen Ruf. Alle finden es richtig, viele lassen es unter Zeitdruck als Erstes weg — schließlich fühlt es sich wie ein Umweg an, erst etwas zu schreiben, das absichtlich nicht funktioniert. Mit einem Agenten im Spiel ändert sich diese Rechnung grundlegend, und das ist die eigentliche Nachricht dieses Kapitels.

0:20 Denn ein Test ist etwas, das eine Maschine verstehen kann: eine Anforderung, die sich ausführen lässt. Wir schauen uns an, wie TDD mit einem Agenten funktioniert, wie Integrationstests ganze Nutzerpfade absichern und wie man Fehler systematisch statt raterisch findet.

Test-Driven Development (TDD)

0:35 Wir bewegen uns in diesem Kapitel von innen nach außen. Zuerst der kleine Kreis: TDD auf Funktionsebene, rot, grün, refaktorieren — mit dem Agenten als Umsetzer. Dann der große Kreis: Integrationstests, die mit Playwright einen echten Browser steuern und ganze Nutzerpfade prüfen. Und zum Schluss der Betrieb: Smoke Tests als schnelle Absicherung vor dem Deployment, und Debugging über Logs. Der rote Faden: Tests steuern, was Claude als Nächstes baut.

TDD mit KI-Agenten

1:05 Beginnen wir mit dem Kern der Methode — und mit der Frage, warum ausgerechnet diese alte Disziplin durch KI eine neue Bedeutung bekommt. Der Grund liegt nicht in der Technik, sondern in der Kommunikation zwischen Ihnen und dem Agenten. Der Dreischritt ist bekannt: erst ein fehlschlagender Test, dann der minimale Code, der ihn grün macht, dann das Aufräumen. Interessant wird die Arbeitsteilung.

1:28 Sie schreiben — oder lassen schreiben — den Test, und damit formulieren Sie die Anforderung. Der Agent liefert den Code. Das ist mehr als eine Aufgabenverteilung, das ist eine Sprachwahl: Ein Test ist eine Anforderung, die keinen Interpretationsspielraum lässt. Wo Prosa Deutungen zulässt, sagt ein Test unmissverständlich, was gelten soll.

1:48 Wer im letzten Kapitel gemerkt hat, wie schwer es ist, eine Regel prüfbar zu formulieren, findet hier die konsequente Fortsetzung — nur dass die Regel jetzt selbst ausführbar ist. Der zweite Punkt ist der entscheidende, deshalb greife ich ihn heraus: Der Agent bekommt ein objektives Erfolgssignal statt Prosa. Ein Agent, der auf eine Beschreibung hin arbeitet, muss selbst einschätzen, ob er fertig ist — und diese Selbsteinschätzung ist die schwächste Stelle im ganzen Ablauf.

2:15 Ein Test nimmt ihm das ab: grün oder nicht grün, ohne Verhandlungsspielraum. Der dritte Punkt ist eine Frage der Reihenfolge: Randfälle vorab zu sammeln, ist etwas völlig anderes, als sie später im Betrieb zu entdecken. Und der vierte ist im Agentenkontext besonders wertvoll — mit einer grünen Suite im Rücken wird Refactoring durch den Agenten überhaupt erst vertretbar.

2:37 Fünf Schritte, und der erste ist der, den man am liebsten überspringt: Randfälle sammeln, am besten schriftlich. Das ist Denkarbeit, und sie lässt sich nicht delegieren, weil nur Sie wissen, was in Ihrer Domäne schiefgehen kann. Danach lassen Sie die fehlschlagenden Tests schreiben. Schritt drei ist der Prüfstein und steht nicht ohne Grund als eigener Punkt da: Bestätigen Sie, dass der Test wirklich rot ist.

3:01 Erst dann implementiert Claude, und zwar minimal — nicht schön, sondern grün. Aufgeräumt wird im fünften Schritt, mit den Tests als Netz. Die Fußzeile ist die Regel, die das Ganze trägt: Der rote Test zuerst ist nicht optional. Zwei kleine Tests, und beide beschreiben etwas, das man in einer Prosa-Anforderung fast sicher vergessen würde: Was passiert bei einer leeren Liste?

3:23 Wie verhält es sich mit negativen Werten? Genau das sind die Randfälle, um die es geht. Der eigentliche Clou steht in der Fußzeile: Die Funktion `summe` gibt es zu diesem Zeitpunkt noch gar nicht. Der Test ist nicht kaputt, er ist bewusst rot — er beschreibt eine Zukunft, die es noch herzustellen gilt. Wenn Sie diesen Gedanken einmal verinnerlicht haben, fühlt sich TDD nicht mehr wie ein Umweg an, sondern wie das Aufschreiben der Aufgabenstellung.

3:49 Jetzt probieren Sie den Zyklus einmal ganz durch, an einem einzelnen Randfall. Wichtig ist die Formulierung des Erfolgskriteriums, und zwar der zweite Teil davon: grün, ohne dass der Test nachträglich aufgeweicht wurde. Das ist die Versuchung, der sowohl Menschen als auch Agenten erliegen — wenn der Test nicht passt, passt man eben den Test an.

4:09 Behalten Sie das im Auge, wir kommen später im Kapitel noch einmal darauf zurück. Und der Hinweis gilt weiterhin: erst rot sehen. Ein Test, der von Anfang an grün ist, prüft möglicherweise überhaupt nichts.

Integrationstests

4:22 Ein grüner Unit-Test ist eine gute Nachricht über ein einzelnes Bauteil. Über das Ganze sagt er wenig. Deshalb gehen wir jetzt eine Ebene höher — dorthin, wo Komponenten aufeinandertreffen und wo die interessanten Fehler wohnen. Stellen Sie sich eine Werkstatt vor, in der jedes Einzelteil eines Autos geprüft wurde und für gut befunden ist.

4:43 Ob der Wagen fährt, wissen Sie damit immer noch nicht — dafür muss jemand einsteigen und losfahren. Integrationstests sind diese Probefahrt. Sie prüfen das Zusammenspiel mehrerer Komponenten, typischerweise Oberfläche und Backend gemeinsam. Playwright ist dabei das Werkzeug, das einen echten Browser fernsteuert: klicken, tippen, warten — wie ein sehr geduldiger Nutzer.

5:04 Claude Code kann diesen Browser bedienen und die Schritte mit API-Aufrufen kombinieren. Heraus kommt ein Szenario, das den Weg des Nutzers tatsächlich abbildet. Der erste Satz beschreibt eine Erfahrung, die vermutlich jeder hier schon gemacht hat: Alle Unit-Tests grün, und das System funktioniert trotzdem nicht. Der Grund ist fast immer derselbe — die Naht zwischen zwei Teilen wurde von keinem Test berührt.

5:28 Genau dort setzen Integrationstests an, denn reale Nutzerpfade laufen nun einmal quer durch alle Schichten. Playwright macht das reproduzierbar, und das ist der Unterschied zum manuellen Durchklicken vor dem Release: Es passiert jedes Mal gleich und ohne Ermüdung. Der letzte Punkt schließt den Bogen zum vorigen Kapitel — Claude erzeugt und pflegt diese Szenarien aus der Spezifikation heraus.

5:50 Lesen Sie diesen Test wie ein Drehbuch, dann erschließt er sich sofort: Seite aufrufen, E-Mail eintippen, Passwort eintippen, absenden — und am Ende die Frage, ob wir tatsächlich auf dem Dashboard gelandet sind. Genau so würde ein Mensch den Login prüfen. Der Wert liegt in der letzten Zeile: Sie prüft nicht, ob eine Funktion das Richtige zurückgibt, sondern ob der Nutzer angekommen ist.

6:13 Und bemerkenswert ist, was dieser Test alles mitprüft, ohne es zu erwähnen — Formular, Übertragung, Authentifizierung, Weiterleitung. Bricht irgendeine dieser Schichten, wird der Test rot. Das ist die Stärke und zugleich die Schwäche: Er sagt Ihnen, dass etwas kaputt ist, nicht was. Bauen Sie jetzt einen durchgehenden Nutzerpfad für Ihre eigene Anwendung.

6:34 Der Hinweis ist entscheidend für den Erfolg der Übung: Fangen Sie mit dem glücklichen Pfad an — dem Ablauf, bei dem alles gut geht. Die Fehlerfälle kommen danach, und sie kommen leichter, wenn das Grundgerüst steht. Achten Sie beim Prüfen auf das Erfolgskriterium: Der Test muss fehlschlagen, wenn eine der beteiligten Schichten bricht.

6:54 Probieren Sie das ruhig aus, indem Sie absichtlich etwas kaputt machen. Ein Integrationstest, der auch bei abgeschaltetem Backend grün bleibt, testet etwas anderes, als Sie denken.

Smoke Tests & Debugging

7:05 Bleibt der Alltag: Was prüft man kurz vor dem Deployment, wenn keine Zeit für die volle Suite ist? Und was tut man, wenn trotzdem etwas schiefgeht? Zwei Themen, die im Betrieb dicht beieinanderliegen. Der Name stammt aus der Elektronik: Man schaltet ein Gerät ein und schaut, ob Rauch aufsteigt. Mehr will ein Smoke Test nicht wissen — laufen die wichtigsten Funktionen überhaupt?

7:28 Das ist bewusst oberflächlich und bewusst schnell, denn diese Prüfung soll vor jedem Deployment durchlaufen, ohne den Ablauf aufzuhalten. Der zweite Teil dieses Kapitels beginnt dort, wo es doch geraucht hat. Beim Debugging spielt Claude Code eine Rolle, die weniger nach Codeschreiben aussieht: Logs lesen, Muster erkennen, eine Hypothese formulieren.

7:48 Also im Grunde genau das, was ein erfahrener Kollege tut, wenn er sich neben Sie setzt. Die ersten beiden Schritte richten das Frühwarnsystem ein: kritische Pfade definieren, automatisch vor jedem Deployment ausführen. Auf „kritisch" liegt die Betonung — nicht alles, was wichtig ist, sondern das, ohne das gar nichts geht.

8:07 Die Schritte drei und vier beschreiben den Ernstfall, und sie beschreiben ihn in einer bestimmten Reihenfolge: erst die Logs zur Analyse geben, dann eine Hypothese bilden, diese gezielt prüfen und daraus den Fix ableiten. Nicht umgekehrt. Und die Fußzeile bewahrt vor einem verbreiteten Missverständnis: Smoke Tests ersetzen die Testsuite nicht. Sie sind der Rauchmelder, nicht die Brandschutzprüfung.

8:30 Der erste Punkt ist der wichtigste dieses Kapitels, und ich hatte ihn vorhin schon angekündigt: Agenten weichen Tests auf. Wenn ein Test hartnäckig rot bleibt, ist die Anpassung des Tests die einfachere Lösung — und sie ist fast immer die falsche. Schauen Sie bei jedem grünen Ergebnis kurz nach, ob der Test noch das prüft, was er prüfen sollte.

8:50 Der zweite Punkt ist die Kehrseite: Flaky Tests, die wegen Timing mal grün und mal rot sind, werden als echte Fehler missverstanden und lösen sinnlose Suchen aus. Punkt drei ist Disziplin — Smoke Tests müssen schnell bleiben. Und der vierte: Ohne Logs analysiert Claude nicht, er rät. Diese letzte Übung ist die realistischste des Kapitels, denn so beginnt Fehlersuche im Alltag: mit einem Logauszug und einer Ahnung.

9:15 Geben Sie Claude echte Logs — nicht Ihre Vermutung, was passiert sein könnte — und lassen Sie eine Hypothese formulieren. Und dann kommt der Teil, der die Übung ausmacht: Verifizieren Sie diese Hypothese, bevor Sie irgendetwas ändern. Am besten mit einem gezielten Test, der den Fehler reproduziert. Blindes Herumprobieren fühlt sich schneller an, führt aber regelmäßig dazu, dass ein Symptom verschwindet und die Ursache bleibt.

9:41 Als Erfolg gilt: Ursache benannt, bestätigt, behoben. Fassen wir zusammen. Der rote Test zuerst ist keine Formalie, sondern die Art und Weise, wie Sie dem Agenten ein eindeutiges Ziel geben — mit einem objektiven Signal, wann er fertig ist. Integrationstests mit Playwright sichern die Nähte, die Unit-Tests nicht sehen, und prüfen den Weg des Nutzers statt einzelner Bausteine.

10:03 Und im Betrieb sorgen Smoke Tests für Frühwarnung, während die Fehlersuche über Logs und Hypothesen läuft statt über Ausprobieren. Im nächsten Kapitel öffnen wir den Agenten nach außen: Das Model Context Protocol verbindet ihn mit Ihren übrigen Systemen.

Grün ist das Ziel

10:18 Rot, grün, refaktorieren — dieser Dreischritt ist älter als jeder Coding-Agent, und trotzdem passt er besser in diese Zeit als je zuvor. Denn er löst genau das Problem, das beim Arbeiten mit einem Agenten am schwersten wiegt: Woran erkennt man, dass etwas wirklich fertig ist? Ein Test beantwortet das ohne Diskussion. Nehmen Sie einen Gedanken mit: Die Qualität Ihrer Tests ist ab jetzt die Qualität Ihrer Anforderungen — mehr noch als früher.

10:45 Fragen und das Material zum Nachlesen finden Sie unter www.HCO.de.