Testgetrieben entwickeln mit KI-Agenten

Worum es geht

Ein KI-Agent liefert in Minuten Code, für den du Stunden bräuchtest. Ohne solides Fundament wird aus dieser Geschwindigkeit aber schnell Leichtsinn statt Fortschritt. Hat vorher niemand festgelegt, was der Code leisten soll, entstehen die Tests hinterher und passen sich dem Code an statt umgekehrt, und das Review kommt nicht hinterher. Das führt zu technischen Schulden und fragilen Systemen.

Der Weg nach vorn ist eine Arbeitsweise, die es lange vor den Agenten gab: testgetriebene Entwicklung. Du schreibst zuerst einen fehlschlagenden Test und dann nur so viel Code, wie dieser Test verlangt. So entsteht schlanker, vollständig getesteter Code, dessen Design aus den Tests folgt. Wer TDD beherrscht, profitiert davon mit und ohne KI.

Mit einem Agenten wird aus dem Test die Spezifikation. Du legst fest, was der Code tun soll, der Agent liefert die Implementierung, und ein automatisiertes Quality Gate entscheidet, ob sie gut genug ist. Dabei siehst du, dass dieselben Praktiken die Zusammenarbeit mit KI-Agenten sicher machen und Menschen schnell arbeiten lassen.

Du lernst TDD in dieser Schulung von Grund auf, in den ersten vier Sitzungen ohne KI, denn ohne dieses Fundament funktioniert der Rest nicht. Du übst es im Ensemble Programming: Alle arbeiten gemeinsam an einer Aufgabe, mit einem Bildschirm und den Rollen Driver, Navigator und Facilitator, die regelmäßig wechseln. In den letzten beiden Sitzungen überträgst du die Arbeitsweise auf deinen eigenen KI-Agenten: Die Spezifikation entsteht im Ensemble, du arbeitest allein oder zu zweit mit deinem Agenten, und das Review findet gemeinsam statt.

Das Beispielprojekt

Ein durchgängiges Beispielprojekt begleitet dich durch die Schulung: EventFlow, ein System für Ticketing und Sitzplatzreservierung mit den Schichten Domain, Application und Infrastructure. Die Werkzeugkette ist vorkonfiguriert: composer ci ist ein Quality Gate aus fünf Stufen, nämlich Coding Standard, statische Analyse mit PHPStan auf Level 10, Architekturregeln mit Deptrac, Tests mit PHPUnit und Mutation Testing mit Infection. Statt sie aufzubauen, liest und schärfst du sie, und das Setup erledigst du vor der ersten Sitzung. Für die ersten Schritte im TDD-Zyklus kommt eine Kata hinzu, in der eine Liste von Terminen ansprechend dargestellt werden soll, Anforderung für Anforderung.

Zwischen den Sitzungen bereiten kurze Aufgaben die nächste Sitzung vor. Die wichtigste folgt auf die vierte Sitzung: Du machst deinen eigenen Agenten im Beispielprojekt einsatzbereit.

Ablauf

1. 1

   Sitzung 1: Tempo braucht ein Netz

   Was fängt welche Stufe des Gates ab?

   • Die These: Tempo allein führt zu Leichtsinn, Kontrolle allein zu Stillstand, und der Weg nach vorn ist Velocity mit Netz
   • Feedback-Schleifen aus Typsystem, Tests, Architektur und Produktion, von denen jede andere Fehler fängt
   • Rundgang durch die Werkzeugkette: composer ci mit seinen fünf Stufen, phpunit.xml, phpstan.neon, deptrac.yaml, infection.json5.dist und der CI-Workflow
   • Fehler live einbauen: Jede Stufe meldet etwas anderes
   • Der Agent als sehr schneller, sehr selbstsicherer Praktikant

   Ergebnis: Ein lauffähiges Projekt, in dem du jede Stufe des Gates an deinem eigenen Code hast anschlagen sehen, und das Value Object Money, testgetrieben und ohne KI entwickelt, mit grünem composer ci

2. 2

   Sitzung 2: Der TDD-Zyklus

   Wie viel Test braucht der nächste Schritt?

   • Wer zuerst den Test schreibt, hat eine Spezifikation, wer zuerst implementiert, nur ein unvollständiges Protokoll
   • Der Guiding Test: von außen anfangen und das Ziel festhalten
   • Kleine Schritte, Fake it und Triangulieren
   • Schwacher und starker Test: Beide sind grün, aber nur einer tötet den Mutanten, und die Ausgabe von Infection lest ihr gemeinsam
   • Ensemble Programming: Rollen, Wechsel, Regeln

   Ergebnis: Mehrere Anforderungen der Termin-Kata, im Ensemble mit einem Guiding Test und im Rhythmus aus Rot, Grün und Refaktorieren umgesetzt

3. 3

   Sitzung 3: Chicago oder London

   Von innen nach außen oder von außen nach innen?

   • Inside-out (Chicago): vom Domänenkern aus, zustandsbasiert prüfen
   • Outside-in (London): vom Use Case aus Kollaborateure entdecken, ihre Kommunikation prüfen, Test Doubles als Entwurfswerkzeug
   • Was testbaren Code ausmacht: klare Verantwortlichkeiten und lose Kopplung, etwa die Zeit als Parameter, statt sie aus einer Uhr zu lesen
   • Ports und Adapter am Beispiel der Zahlungs-Naht von EventFlow

   Ergebnis: Das Aggregat Event mit Reservation, im Ensemble inside-out entwickelt, bei dem ein Platz nur einmal reserviert werden kann und nach Beginn der Veranstaltung keine Reservierung mehr möglich ist, und Outside-in an einem eigenen Beispiel gesehen

4. 4

   Sitzung 4: Refaktorieren

   Wann und wie räumst du auf, ohne etwas kaputtzumachen?

   • Wann refaktorieren: nach jedem Grün, bevor die nächste Anforderung kommt
   • Produktivcode und Testcode refaktorieren, mit Tests, die Verhalten prüfen statt Implementierungsdetails
   • Domain Events aufzeichnen und prüfen
   • Mutation Testing auf dem Aggregat: welcher Mutant überlebt und warum

   Ergebnis: Ein refaktoriertes Aggregat mit dem Domain Event SeatReserved und eine Auswertung der überlebenden Mutanten, die Lücken in den Tests von äquivalenten Mutanten unterscheidet

5. 5

   Sitzung 5: Tests als Spezifikation für den Agenten

   Was musst du festlegen, damit der Agent das Richtige baut?

   • Die Umkehrung: statt „Schreib mir eine Klasse, die X kann“ jetzt „Erfülle diese Tests, ohne sie zu verändern“
   • Die Reihenfolge: rote Akzeptanztests, Architekturregeln, der Agent implementiert, bis composer ci grün ist, Review der Domänenlogik, Mutation Testing
   • Ein Briefing für den Agenten schreiben und den Agenten stoppen
   • Das gemeinsame Review: unerwartete Abhängigkeiten, Logik in der falschen Schicht, überlebende Mutanten, veränderte Tests

   Ergebnis: Der Use Case PurchaseTicket, im Ensemble ohne KI spezifiziert und von deinem Agenten implementiert, und ein gemeinsames Review seines Ergebnisses

6. 6

   Sitzung 6: Das Quality Gate härten und der Transfer

   Was hält schlechten Code auf, egal woher er kommt?

   • Branch Protection als eigentliches Sicherheitsnetz, denn lokal lässt sich alles überspringen
   • Objektive Gates statt Policies wie „KI-Code muss markiert werden“
   • Kosten und Nutzen: welche Gates bei jedem Commit laufen, welche vor dem Merge und welche nachts
   • Live: Required Status Checks und ein gesperrter Merge-Button
   • Das Gate schärfen und brechen: eine Schwelle für den Mutation Score, Schutz gegen eine wachsende PHPStan-Baseline, Test-Pflicht für neue Klassen, und absichtlich schlechte Commits, von dir geschrieben oder vom Agenten erzeugt, denn das Gate ist blind für die Herkunft des Codes

   Ergebnis: Ein geschärftes Gate, das jeden schlechten Commit blockiert, egal ob von Mensch oder Maschine, und ein Plan, in welcher Reihenfolge du die fehlenden Gates in deinem Projekt nachrüstest und welches am Montag kommt

Für wen

• PHP-Entwicklerinnen und -Entwickler, die ihre Software zielgerichtet und mit hoher Qualität entwickeln wollen
• Entwicklerinnen und Entwickler und Teams, die KI-Agenten einsetzen oder einführen wollen, ohne die Kontrolle über die Qualität abzugeben
• Alle, die TDD bisher nur vom Hörensagen kennen oder es schon einmal versucht und wieder aufgegeben haben

Voraussetzungen

• Praktische Erfahrung mit PHPUnit und Kenntnisse in objektorientierter Programmierung in PHP; schreibst du noch keine Tests, beginnst du mit „Testen verstehen“ und „Agentic PHPUnit“
• Für die Übungen eine lokale Umgebung mit PHP 8.5, Xdebug oder PCOV, Git und einer IDE, alternativ Podman oder Docker mit dem mitgelieferten Containerfile
• Ab der fünften Sitzung ein KI-Agent deiner Wahl, etwa Claude Code, Copilot Agent Mode oder Cursor, der im Projekt Dateien schreiben und Kommandos ausführen darf; Kosten und Kontingent für deinen Agenten trägst du selbst; wenn du im Unternehmen keinen Agenten einsetzen darfst, arbeitest du mit einer anderen teilnehmenden Person zusammen

Das nimmst du mit

• Du entwickelst ein Feature testgetrieben, vom Guiding Test bis zum refaktorierten Code
• Du entscheidest begründet, ob du inside-out oder outside-in vorgehst
• Du formulierst Anforderungen als Tests, die ein KI-Agent erfüllen muss, ohne sie verändern zu dürfen
• Du beurteilst den Code eines Agenten mit Quality Gate und Mutation Testing statt nach Augenmaß
• Du weißt, welches Gate du in deinem Projekt als Erstes nachrüstest, und warum

Verwandte Schulungen

Diese Schulung ist Teil des Lernpfads Arbeiten mit KI-Agenten.