Agentic PHPUnit

Worum es geht

Tests schreiben war lange mühsam. Heute erledigt das ein Coding Agent in Sekunden: Er liest deinen Code und erzeugt Dutzende Tests, alle grün, und die Coverage steigt. Nur schreibt der Agent auf, was dein Code tut, nicht, was er tun soll. Hat dein Code einen Fehler, bestätigen die Tests ihn. Und weil der Agent jedes Implementierungsdetail prüft, zerbrechen seine Tests beim nächsten Refactoring, obwohl sich am Verhalten nichts geändert hat.

Ein generierter Test ist deshalb noch kein geprüfter Test. Fachlich geprüft ist er erst, wenn ein Mensch beurteilt hat, dass seine Erwartung stimmt. Dafür musst du wissen, wie ein guter PHPUnit-Test aussieht, und du musst ihn gegen die Anforderung lesen, nicht gegen den Code.

In dieser Schulung arbeitest du mit deinem eigenen Coding Agent. Er schreibt die Tests, du beurteilst sie. Du lernst, ihn mit einer AGENTS.md und den richtigen Aufträgen anzuleiten, und setzt ihm Leitplanken, die schwache Tests aufhalten, bevor du sie lesen musst. Vor allem lernst du den Unterschied zwischen Tests, die nur das Ist-Verhalten festhalten, und fachlichen Tests, die lange halten.

Wenig selbst schreiben, viel lesen

Jede Übung läuft mit deinem eigenen Agenten, allein oder zu zweit. Weil Agenten nicht deterministisch antworten, kommen verschiedene Ergebnisse heraus, und das ist gewollt: Im gemeinsamen Review vergleichst du, was die Agenten erzeugt haben, und aus mehreren Testsuiten lernst du mehr als aus einer. Du schreibst selbst wenig Testcode, aber du liest, beurteilst und korrigierst viel davon. So lernst du, wie ein PHPUnit-Test aussehen muss.

Du übst an einem Warenkorb mit Rabatten, Versand und Lagerbestand. Zu ihm gibt es eine Fachspezifikation als Text, damit du Tests gegen die Anforderung prüfen kannst statt gegen den Code. Die Konfiguration einzelner Agenten siehst du in Vorführungen, weil sie sich schnell ändert. Gelehrt werden die Mechanismen dahinter: Anweisung, Umgebung und Leitplanke.

Ablauf

1. 1

   Sitzung 1: Der Agent schreibt, du prüfst

   Was taugt ein Test, den du nicht selbst geschrieben hast?

   • Wie ein PHPUnit-Test aussehen muss: Testklasse und Testmethode, Namen als Sätze, Arrange, Act, Assert, assertSame(), expectException(), Data Provider mit benannten Datensätzen, createStub() und createMock()
   • Typische Schwächen generierter Tests: Zusicherungen, die nichts prüfen können, nachgebaute Logik im Test, assertTrue(true) als Feigenblatt, Mocks für alles, Tests für private Details
   • Das Prüfverfahren: den Produktivcode absichtlich brechen, denn ein Test, der dabei grün bleibt, ist wertlos, auch bei 100 % Coverage
   • Behalten, umschreiben, löschen: Kriterien für das Urteil

   Ergebnis: Ein Urteil über jeden Test, den dein Agent ohne Vorgaben für Discount geschrieben hat, geprüft durch absichtliches Brechen des Codes, und ein schwacher Test, den du selbst umgeschrieben hast

2. 2

   Sitzung 2: Generiert ist nicht geprüft

   Woher weiß der Agent, was richtig ist?

   • Woher die Erwartung kommt: Ein Agent, der den Code liest, nimmt den Code als Orakel, und seine Tests halten als Characterization Tests das Ist-Verhalten fest, Fehler eingeschlossen
   • Wofür Characterization Tests taugen: als kurzlebiges Sicherheitsnetz vor einem Refactoring, aber nicht als Spezifikation
   • Fachlich geprüft heißt: Ein Mensch hat anhand der Anforderung beurteilt, dass die Erwartung stimmt
   • Fachlich prüfen mit Testnamen als fachlichen Aussagen, --testdox als Bericht, den auch Fachleute lesen können, und Grenzfällen aus der Anforderung statt aus dem Code
   • Den Agenten aus der Anforderung testen lassen statt aus dem Code
   • Den Status sichtbar machen, etwa mit getrennten Testsuites oder Gruppen, damit niemand einen ungeprüften Test für eine Spezifikation hält

   Ergebnis: Die Tests deines Agenten für Shipping, gegen die Fachspezifikation geprüft, der Test, der einen versteckten Fehler festgeschrieben hat, mit korrigierter Erwartung und damit rot, und ein Vergleich mit Tests, die der Agent nur aus der Fachspezifikation geschrieben hat

3. 3

   Sitzung 3: Den Agenten anleiten

   Was muss der Agent wissen, damit er die richtigen Tests schreibt?

   • Was nur im Prompt steht, vergisst der Agent: AGENTS.md und agentenspezifische Dateien wie CLAUDE.md halten es fest
   • Was hineingehört: die Testvorgaben des Teams, ein Vorbildtest, die Kommandos für den Testlauf und Verbote, etwa bei einer Testaufgabe den Produktivcode nicht zu ändern, bestehende Tests nicht abzuschwächen und keine Test Doubles für Wertobjekte zu verwenden
   • Kontextbudget: knapp und konkret statt vollständig
   • Aufträge, die zu besseren Tests führen: klein, mit der Anforderung statt dem Code als Quelle und mit einer Testliste aus Testfällen und Grenzfällen, die du prüfst, bevor der Agent die Tests schreibt
   • Den Agenten stoppen, wenn er abschweift

   Ergebnis: Eine AGENTS.md mit Testvorgaben für das Übungsprojekt, ausgehend von deiner Testrichtlinie aus „Tests mit System“ oder einer Vorlage, und Tests für Discount, die der Agent diesmal nach einer Testliste geschrieben hat, im Vergleich mit denen aus der ersten Sitzung

4. 4

   Sitzung 4: Leitplanken setzen

   Was hält einen schlechten Test auf, bevor du ihn liest?

   • Drei Mechanismen: Anweisung in der AGENTS.md, Umgebung aus Composer-Skripten, Umgebungsvariablen und freigegebenen Kommandos, und Leitplanken, die einen Verstoß technisch verhindern
   • Eine strenge PHPUnit-Konfiguration: riskante Tests und Warnungen scheitern lassen, zufällige Reihenfolge, die Angabe des abgedeckten Codes verlangen
   • PHPStan mit der PHPUnit-Erweiterung auf dem Testcode
   • Mutation Testing mit Infection auf dem geänderten Code, damit Tests auffallen, die nichts prüfen
   • Hooks, die bei einer Testaufgabe Änderungen am Produktivcode oder an bestehenden Tests abweisen
   • Ein Einstiegspunkt für alle Prüfungen, und die CI als letzte Instanz

   Ergebnis: Leitplanken aus PHPUnit-Konfiguration, statischer Analyse, Mutation Testing und Hooks, unter denen dein Agent im Übungsprojekt arbeitet und die einen wertlosen Test zurückweisen, bevor du ihn lesen musst

5. 5

   Sitzung 5: Tests, die bleiben

   Welche Tests überleben das nächste Refactoring?

   • Warum generierte Tests fragil sind: Statt Verhalten prüfen sie private Details, Aufrufreihenfolgen und Datenstrukturen, und sie ersetzen jede Abhängigkeit
   • Fachliche Tests: über öffentliche Schnittstellen und Anwendungsfälle, in der Sprache der Domäne, mit Stubs statt Mocks, wo keine Kommunikation geprüft wird, und so weit wie möglich entkoppelt von Framework, Datenbank und HTTP
   • Domänenspezifische Zusicherungen und Builder für Testdaten
   • Kurzlebig und langlebig: generierte Characterization Tests bewusst als Netz für ein Refactoring einsetzen und danach löschen oder zu fachlichen Tests befördern

   Ergebnis: Fachliche Tests anstelle der fragilen generierten, die vor und nach einem vorbereiteten Refactoring grün sind, das kein Verhalten ändert, und die beim absichtlichen Brechen des Codes rot werden

6. 6

   Sitzung 6: Am eigenen Code

   Welche Tests behältst du, welche beförderst du, welche löschst du?

   • Die Arbeitsweise im Überblick: anleiten, schreiben lassen, beurteilen, fachlich prüfen, entkoppeln
   • Wann generierte Tests genügen, wann ein Test fachlich geprüft werden muss und wer das tut
   • Behalten, befördern, löschen: Regeln für generierte Tests im Bestand
   • Tests im Pull Request prüfen: worauf ein Review bei generierten Tests achtet

   Ergebnis: Tests, die dein Agent mit AGENTS.md und Leitplanken für deinen mitgebrachten Code geschrieben hat, fachlich geprüft und zum Teil befördert, und der Entwurf einer Vereinbarung für dein Team

Für wen

• PHP-Entwicklerinnen und -Entwickler, die Tests von Coding Agents schreiben lassen oder das vorhaben
• Teams mit vielen generierten Tests, von denen niemand weiß, welche etwas taugen
• Entwicklerinnen und Entwickler, die PHPUnit für die Arbeit mit Agenten lernen wollen

Voraussetzungen

• Erfahrung mit objektorientierter Programmierung in PHP
• Die Begriffe des Testens, wie sie „Testen verstehen“ vermittelt; hilfreich sind außerdem „Startklar mit PHPUnit“ und „Tests mit System“
• Ein Coding Agent deiner Wahl, etwa Claude Code, Copilot Agent Mode, Cursor oder Junie, 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
• Für die Übungen PHP 8.5, Composer, Git und eine IDE, alternativ Podman oder Docker mit dem mitgelieferten Containerfile
• Für die sechste Sitzung ein überschaubares Stück eigenen Codes, etwa eine Klasse mit fachlicher Logik

Das nimmst du mit

• Du erkennst gute und schlechte PHPUnit-Tests, auch wenn sie generiert sind
• Du prüfst Tests, indem du den Code brichst, statt der grünen Ausgabe zu glauben
• Du prüfst generierte Tests fachlich gegen die Anforderung und findest Fehler, die sie festgeschrieben haben
• Du leitest deinen Agenten mit einer AGENTS.md an und setzt ihm Leitplanken, sodass er Tests nach euren Vorgaben schreibt
• Du machst aus fragilen generierten Tests fachliche Tests, die das nächste Refactoring überstehen
• Du legst für dein Team fest, wie ihr generierte und fachlich geprüfte Tests unterscheidet

Verwandte Schulungen

Diese Schulung ist Teil der Lernpfade Einstieg ins Testen, Testen mit PHPUnit, Arbeiten mit KI-Agenten, Testvorgaben im Team, Sicherheit.