Testcode erzeugen mit dem Generator-Agenten

Testcode erzeugen mit dem Generator-Agenten

0:00 Aus dem geprüften Plan wird jetzt Code. Das ist der Moment, auf den alle warten — und gleichzeitig der Moment, an dem die eigentliche Arbeit beginnt. Denn der Generator liefert in Minuten, was von Hand Stunden gedauert hätte, und genau diese Geschwindigkeit ist die Falle: Ein Diff mit zwölf neuen Testdateien liest sich niemand gern durch.

0:18 In diesem Modul geht es deshalb um zwei Dinge zugleich: wie man den Generator gut beauftragt und wie man sein Ergebnis so prüft, dass die Prüfung nicht zur Formalie wird.

Vom Plan zum ausführbaren Test

0:28 Beginnen wir mit dem Handwerk: Was macht der Generator eigentlich, was braucht er dafür, und wie behalten wir die Verbindung zum Plan? Das Handwerk hier ist schnell erklärt. Die Kunst liegt darin, den Auftrag so zu stellen, dass hinterher wenig zu korrigieren ist — und die Verbindung zum Plan nicht verloren geht. Der Generator nimmt einen Plan aus dem Spezifikationsordner und erzeugt daraus Testdateien.

0:52 Dabei stützt er sich auf den Seed-Test und auf die Konventionen, die er im Projekt vorfindet — je klarer die sind, desto weniger erfindet er. Die erste Fassung kann Fehler enthalten; der Generator führt Tests aus und korrigiert Offensichtliches, bevor er abgibt. Erwarten Sie also keinen fertigen Beitrag, sondern einen guten ersten Entwurf. Ungefähr so, wie ein erfahrener Kollege schnell etwas hinschreibt und sagt: Schau mal, ob das passt.

1:18 Fünf Schritte, und drei davon sind Vorgaben. Den überarbeiteten Plan benennen — den überarbeiteten, nicht den rohen. Seed-Test und vorhandene Fixtures als verbindlichen Kontext nennen, damit der Agent nicht sein eigenes Setup erfindet. Zielordner und Dateinamen vorgeben. Die erlaubten Abstraktionen festlegen, und zwar knapp: In dieser Phase noch keine Page Objects — dafür ist es zu früh, wir wissen ja noch gar nicht, was sich wiederholt.

1:44 Und der fünfte Schritt ist eine Selbstverpflichtung: den Diff lesen, bevor irgendein Test läuft. Hier sehen Sie, wie ein erzeugter Test idealerweise aussieht: Der Name nennt die fachliche Aussage, die Schritte sind kurz, und die Prüfung steht am Ende. Was Sie nicht sehen, ist genauso wichtig — kein Setup-Berg vor der ersten Handlung, keine Prüfungen nebenbei. Beachten Sie den Testnamen: „Gutschein senkt die Summe".

2:09 Wenn dieser Test rot wird, wissen Sie ohne einen Blick in den Code, was kaputt ist. Diese Eigenschaft ist kein Stilfrage, sie entscheidet später darüber, wie schnell Sie einen Fehlschlag einordnen können. Diese vier Zeilen sind eine Kette, und sie hat einen Namen: Traceability. Von der Anforderung über das Szenario im Plan zum Test und schließlich zum Trace des Laufs.

2:32 Der Nutzen zeigt sich immer erst später — dann aber deutlich. Ein Test wird rot: Welche Regel ist betroffen? Eine Anforderung ändert sich: Welche Tests muss ich anfassen? Jemand fragt nach der Testabdeckung: Sie zeigen auf den Plan statt auf eine Prozentzahl. Ohne diese Kette haben Sie nach drei Monaten einen Ordner voller Tests, deren Zweck niemand mehr rekonstruieren kann.

2:55 Vier Fallen bei der Erzeugung. Ohne geprüften Plan zu starten erzeugt Beliebigkeit — der Agent nimmt sich dann, was er auf der Seite findet. In vorhandene Dateien hineinschreiben zu lassen kostet Sie die Historie und macht den Diff unlesbar. Abstraktionen zuzulassen, bevor klar ist, was sich wiederholt, führt zu Hüllen um einen einzigen Aufrufer — dazu mehr in Modul acht.

3:18 Und der vierte Punkt ist der wichtigste: Der erste grüne Lauf ist keine Abnahme. Er sagt nur, dass der Code syntaktisch funktioniert.

Woran man einen atomaren Test erkennt

3:26 Damit wir gleich beurteilen können, was der Generator liefert, brauchen wir ein Qualitätsmaß. Es ist einfacher, als man denkt — und es hat einen Namen. Ohne Maßstab wird jedes Review zur Geschmacksfrage. Der Maßstab, den wir hier benutzen, ist alt, bewährt und lässt sich in einem Satz sagen. Danach haben Sie ein Kriterium, über das sich nicht streiten lässt.

3:49 Atomar heißt: ein Test, eine fachliche Aussage. Er stellt seinen Ausgangszustand selbst her, führt eine Handlung aus und behauptet ein Ergebnis. Der Nutzen ist diagnostisch. Stellen Sie sich eine Sicherung im Haus vor, die den ganzen Haushalt abschaltet — Sie wissen dann, dass etwas kaputt ist, aber nicht was. Viele kleine Sicherungen sagen Ihnen sofort: Küche.

4:11 Genau so verhält sich ein atomarer Test: Wenn er fehlschlägt, ist die Menge möglicher Ursachen klein, und die Diagnose steht praktisch schon im Testnamen. Vier Vorteile, die alle aus derselben Eigenschaft folgen. Der Fehlschlag benennt die Ursache, statt sie nur zu melden. Der Test bleibt lesbar und überlebt Änderungen an anderen Stellen, weil er wenig berührt. Er lässt sich gefahrlos parallel ausführen — das wird in Modul zehn wichtig.

4:38 Und Reparaturen bleiben klein, weil nur eine Aussage betroffen ist. Übrigens ist das auch ein wirtschaftliches Argument: Große Tests werden nicht repariert, sie werden irgendwann übersprungen. Und ein übersprungener Test kostet weiter Wartung, ohne etwas abzusichern. Die linke Spalte enthält Symptome, die Sie im Diff sofort erkennen können. Ein „und" im Testnamen bedeutet zwei Aussagen.

5:02 Zwanzig Schritte vor der ersten Prüfung bedeutet: Das Setup gehört in eine Fixture. Eine Prüfung nebenbei, etwa der Navigation, ist eine fremde Aussage und gehört gestrichen. Und ein Test, der auf dem Vorgänger aufbaut, ist schlicht nicht isoliert. Wichtig: Erzeugte Tests neigen besonders zur zweiten Zeile. Das ist logisch — der Agent hat diesen Weg gerade erkundet und schreibt ihn auf, so wie man den Weg zum Bahnhof erzählt, den man selbst gerade gegangen ist.

5:31 Hier sehen Sie die Aufteilung in der Praxis. Aus einem überladenen Test sind zwei geworden: einer für den Fehlerfall, einer für den Erfolgsfall. Beide starten aus demselben Fixture-Zustand, keiner setzt den anderen voraus — Sie könnten sie in beliebiger Reihenfolge ausführen. Der Aufwand für diese Trennung ist minimal, der Gewinn zeigt sich beim ersten Fehlschlag.

5:52 Und noch etwas fällt auf: Beide Tests sind jetzt so kurz, dass man sie im Vorbeigehen liest. Lesbarkeit ist bei Tests kein Luxus, sie ist die halbe Absicherung.

KI-erzeugte Tests prüfen

6:02 Und damit zum Herzstück dieses Moduls — dem Review. Wir machen daraus keine Geschmacksfrage, sondern eine Checkliste, die man in zehn Minuten abarbeiten kann. Jetzt kommt der Teil, der die eigentliche Wertschöpfung ausmacht — und der in der Praxis am häufigsten abgekürzt wird. Wir machen daraus eine Checkliste, die in zehn Minuten abgearbeitet ist.

6:24 Der wichtigste Satz zuerst: Ein erzeugter Test kann grün sein und trotzdem wertlos. Zum Beispiel, wenn er nichts Fachliches behauptet. Oder wenn seine Erwartung aus der Oberfläche abgeschrieben wurde und damit einen bestehenden Fehler festschreibt. Oder wenn er nur zufällig funktioniert, weil die Testdaten gerade passen. Das Review prüft deshalb nicht die Lauffähigkeit — die prüft der Runner viel zuverlässiger als Sie.

6:48 Es prüft die Aussage. Das ist eine andere Tätigkeit als klassisches Code-Review, und sie will geübt sein. Sechs Prüfpunkte, und jede Zeile ist ein Ablehnungsgrund — kein Hinweis für später. Locators, die an Struktur statt an Bedeutung hängen. Assertions, die nur Sichtbarkeit prüfen. Klicks und Prüfungen ohne Bezug zur Aussage. Feste Wartezeiten. Zufallswerte oder feste Datenbanksätze als Testdaten. Und Abhängigkeiten von anderen Tests.

7:17 Sie kennen inzwischen jeden einzelnen Punkt aus Modul zwei — das ist kein Zufall. Das Review erzeugter Tests ist nichts anderes als konsequent angewandtes Playwright-Grundwissen. Die Reihenfolge ist entscheidend, deshalb wörtlich: Erst die Testnamen lesen — steht dort eine fachliche Aussage? Dann die Assertions — sichern sie diese Aussage wirklich ab?

7:40 Dann den Ausgangszustand — stellt der Test ihn selbst her? Dann gegen den Plan halten — was fehlt, was ist doppelt? Und erst zum Schluss ausführen. Diese Reihenfolge ist unbequem, weil das Ausführen so verlockend ist. Aber ein grüner Lauf färbt Ihr Urteil: Wer erst grün sieht und dann liest, liest nachsichtiger. Das ist keine Charakterschwäche, das ist einfach so.

8:04 Vier Fallen im Review selbst. Den Diff zu überfliegen, weil der Lauf grün ist — darüber haben wir gerade gesprochen. Assertions zu akzeptieren, die den aktuellen Fehler zur Erwartung machen: Das ist der schwerste Schaden, weil er dauerhaft ist. Zufällige Testdaten zu dulden, macht jeden Fehlschlag unreproduzierbar und damit unbrauchbar.

8:24 Und Review auf Formatierung zu reduzieren ist die angenehmste Variante, weil man dabei zügig vorankommt — nur prüft man dann genau das, was ein Formatierer ohnehin erledigt. Jetzt sind Sie dran: Begutachten Sie einen erzeugten Test anhand des Rasters und benennen Sie die Mängel. Mindestens drei belegte Befunde — und belegt heißt: mit Fundstelle im Code und einer Begründung aus dem Plan. Diese zweite Hälfte ist die anspruchsvolle.

8:51 „Gefällt mir nicht" ist kein Befund; „prüft nur Sichtbarkeit, der Plan verlangt aber den Wert" ist einer. Wer diese Übung zweimal gemacht hat, liest Diffs anders — und merkt, wie schnell ein strukturiertes Review tatsächlich geht.

Prompt-Muster für die Testerzeugung

9:05 Zum Schluss die Frage, wie man den Generator so beauftragt, dass das Review kurz ausfällt. Die Antwort steckt in drei Bestandteilen. Zum Abschluss die Gegenrichtung: Statt hinterher zu korrigieren, sorgen wir vorne für bessere Ergebnisse. Drei Bestandteile genügen dafür — und einer davon fehlt fast immer. Danach ist der Auftrag ein Artefakt im Repository und nicht mehr eine Eingebung im Chatfenster.

9:30 Ein brauchbarer Auftrag hat Kontext, Ziel und Einschränkungen. Kontext: woraus darf der Agent arbeiten. Ziel: was soll entstehen. Einschränkungen: was darf er nicht. Der dritte Teil fehlt fast immer — und dann erfindet der Agent Struktur. Nicht aus Übermut, sondern weil er hilfreich sein will: Er sieht drei ähnliche Zeilen und baut eine Abstraktion, er vermisst eine Hilfsfunktion und legt sie an.

9:55 Das Ergebnis ist mehr Architektur, als das Projekt gerade braucht — und mehr Diff, als jemand liest. Fünf Bestandteile, die man einmal formuliert und dann wiederverwendet. Kontext benennen: Plan, Seed-Test, Fixtures, Konventionen. Ziel benennen: welche Szenarien in welcher Datei. Einschränkungen setzen: keine neuen Abhängigkeiten, keine neuen Ordner.

10:19 Erlaubte Abstraktionen aufzählen und alles andere ausschließen — die positive Liste wirkt besser als ein Verbot. Und Review-Kriterien mitgeben, damit der Agent selbst dagegen prüft. Der letzte Punkt spart erstaunlich viel: Was er selbst findet, müssen Sie nicht mehr finden. Fünf Zeilen, die im Repository liegen und versioniert werden. Das ist der eigentliche Punkt dieser Folie: Der Auftrag ist ein Artefakt wie jedes andere.

10:46 Liegt er nur im Chatverlauf, weicht jeder Lauf vom vorigen ab, und zwei Kollegen bekommen unterschiedliche Ergebnisse, ohne zu verstehen warum. Liegt er im Repository, können Sie ihn verbessern — und die Verbesserung wirkt für alle. Behandeln Sie Prompts wie Konfiguration: sichtbar, versioniert, überprüfbar. Das ist unspektakulär und einer der größten Hebel überhaupt.

11:10 Zum Abschluss ein Argument, das nichts mit KI zu tun hat und trotzdem hier entscheidet: Ein kleiner Diff wird gelesen, ein großer wird durchgewinkt. Das war schon bei menschlichen Pull Requests so; mit einem Agenten, der in Minuten sehr viel Code erzeugt, wird es zur zentralen Frage. Begrenzte Aufträge verhindern Umbauten, die niemand angefragt hat. Wiederholbare Aufträge machen Ergebnisse vergleichbar.

11:33 Und wer die Regeln kennt, kann Abweichungen im Review sofort benennen. Im nächsten Modul geht es darum, was passiert, wenn diese Tests später rot werden.