Teststrategie für KI-generierten Code

Teststrategie für KI-generierten Code

0:00 Im siebten Modul geht es um Tests — und zwar um eine These, die schärfer ist als die übliche. Tests waren immer nützlich. Unter agentischer Entwicklung werden sie zur Voraussetzung. Der Grund liegt in einer Verschiebung, die Sie sofort wiedererkennen werden: Wer eine Funktion selbst schreibt, hat beim Schreiben über jeden Zweig nachgedacht.

0:20 Wer eine fertige Funktion liest, hat einen Eindruck. Und Eindrücke täuschen bei Code besonders zuverlässig. Der Test schließt genau diese Lücke — er verwandelt „sieht richtig aus" in „verhält sich richtig".

Teststrategie für KI-generierten Code

0:33 Wir sind mitten im zweiten Tag, dem Tag der Verifikation. Nachdem wir den Kontext geordnet haben, kommt jetzt das wichtigste Prüfinstrument. Und Sie werden merken, dass sich der Blick dabei verschiebt: Es geht weniger darum, mehr Tests zu haben, als darum, zu wissen, was ein einzelner Test eigentlich belegt. Am Ende dieses Moduls steht eine Probe, die zwei Minuten kostet und mehr aussagt als jede Abdeckungszahl.

Warum mehr Tempo mehr Verifikation verlangt

0:58 Beginnen wir mit der Begründung, warum sich das Verhältnis zu Tests geändert hat. Es liegt nicht daran, dass generierter Code schlechter wäre — das ist er nicht zwangsläufig. Es liegt an einer veränderten Beziehung zwischen Ihnen und dem Code. Diese Beziehung bestimmt, was Sie überhaupt beurteilen können, und daraus folgt alles Weitere in diesem Modul.

1:18 Der Unterschied zwischen Schreiben und Lesen ist größer, als man denkt. Wer eine Funktion selbst schreibt, geht dabei jeden Zweig durch — er muss ja entscheiden, was in jedem Fall passieren soll. Am Ende trägt er ein Modell davon im Kopf. Wer dieselbe Funktion fertig liest, hat dieses Modell nicht. Er hat einen Eindruck. Und das Auge liest zuverlässig über Randfälle hinweg, die der Verstand nie geprüft hat.

1:43 Genau dort setzt der Test an: Er ersetzt den Eindruck durch eine Aussage über das Verhalten. Diese Tabelle beschreibt eine Grenze, und ich halte sie für das nützlichste Bild des ganzen Moduls. Alles, was von Tests abgedeckt ist, prüft die Maschine bei jedem Lauf — dort darf ein Agent arbeiten, ohne dass jemand nachts wach liegt.

2:03 Alles, was nicht abgedeckt ist, muss ein Mensch mit den Augen prüfen. Und daraus folgt etwas Unbequemes: Nicht die Erzeugungsgeschwindigkeit bestimmt Ihr Tempo, sondern die Größe der geprüften Fläche. Wer schneller werden will, vergrößert diese Fläche. Alles andere ist Selbstbetrug. Vier Punkte, die zusammen die These tragen. Tests schließen die Lücke zwischen Eindruck und Verhalten — das ist der fachliche Kern.

2:28 Wer die abgedeckte Fläche vergrößert, vergrößert den Bereich, in dem Autonomie sicher ist. Und wer sie klein lässt, kauft Erzeugungstempo ein, das er hinterher nicht abnehmen kann. Das ist der Satz, den ich Ihnen mitgeben möchte: Eine Testsuite ist unter diesen Bedingungen keine Qualitätsmaßnahme mehr. Sie ist die Bedingung dafür, das Werkzeug überhaupt sinnvoll einzusetzen.

Testziele statt Testmengen

2:51 Damit zur ersten praktischen Frage, und sie ist meist falsch gestellt. Wie viele Tests brauchen wir? Diese Frage führt in die Irre, weil sie eine Zahl zur Antwort hat — und Zahlen lassen sich erreichen, ohne dass etwas besser wird. Es gibt eine bessere Frage, aus der fast alles Weitere folgt. Die brauchbare Frage lautet: Welche Aussage soll dieser Test belegen, und was würde ich glauben, wenn er grün ist? Zwei Teile, und der zweite ist der interessantere.

3:19 Denn wenn Sie auf „was würde ich glauben" keine Antwort finden, hat der Test keinen Wert — dann läuft nur Code durch. Diese Frage können Sie an jeden einzelnen Test stellen, an eigene wie an generierte, und sie kostet Sekunden. Sie ist zugleich der wirksamste Hebel im Auftrag an einen Agenten. Sie verhindert zwei sehr verschiedene Fehlformen. Die erste: hundert Prüfungen derselben trivialen Sache, während die eine fachliche Regel fehlt, um die es eigentlich geht.

3:47 Die zweite: Tests ohne Aussage, die nur belegen, dass ein Objekt sich erzeugen lässt. Und dann der Punkt, der für die Zusammenarbeit mit Agenten entscheidend ist: Ein Auftrag, der die zu belegenden Aussagen aufzählt, liefert brauchbare Tests. Ein Auftrag, der eine Abdeckungszahl nennt, liefert zuverlässig Tests, die diese Zahl erreichen und nichts belegen.

4:08 Der erste Punkt ist die falsch gestellte Frage von eben. Der zweite ist der wichtigste in der Praxis: Eine Abdeckungsquote zu beauftragen heißt, sie zu bekommen — und zwar wörtlich, mit Tests, deren einziger Zweck das Erreichen der Zahl ist. Beim Agenten funktioniert das noch zuverlässiger als beim Menschen, weil ihm der Aufwand dafür nichts ausmacht.

4:29 Der dritte Punkt ist die praktische Anwendung: Tests akzeptieren, die keinen Satz über die Fachlichkeit belegen. Und der vierte fasst zusammen — Testmenge ist nicht Testgüte.

Testarten und ihre Reichweite

4:39 Jetzt zur Frage, welche Art von Test wann angemessen ist. Ich schlage vor, das über die Reichweite zu sortieren statt über Begriffe — die Begriffsdebatte über Unit- und Integrationstests führt erfahrungsgemäß zu nichts. Reichweite ist dagegen praktisch: Sie sagt, wie viel ein Test sieht und was er dafür bezahlt. Lesen Sie die rechte Spalte als Preisschild.

5:01 Ein Test kleiner Reichweite prüft eine Einheit isoliert — schnell und präzise im Fehlerhinweis, aber blind für alles, was zwischen den Einheiten passiert. Mittlere Reichweite prüft ein Modul mit seinen echten Nachbarn: langsamer, dafür näher an der Wirklichkeit. Ein Vertragstest prüft die Vereinbarung zwischen zwei Seiten, ohne beide zusammen zu betreiben — der Preis ist, dass beide Seiten ihn pflegen müssen.

5:26 Und große Reichweite fährt das ganze System hoch: aussagekräftig, langsam, störanfällig. Keine dieser Zeilen ist besser als die andere. Die Testpyramide empfiehlt viele kleine und wenige große Tests, und als Ausgangspunkt ist das vernünftig. Als Vorschrift ist sie es nicht. Denn wo das Risiko liegt, entscheidet der Zuschnitt — nicht die Figur. Im Fahrtenbuch liegt es in der Abrechnung, weil dort viele Teile zusammenkommen.

5:51 Dort sind mittlere Tests die wirtschaftlichere Wahl, auch wenn die Form dann keine Pyramide mehr ist. Eine Randnotiz zur Zuschreibung: Die Pyramide wird meist Mike Cohn zugeschrieben, gezeichnet hat sie Martin Fowler bereits 2003 im Gespräch mit Lisa Crispin.

Tests aus Akzeptanzkriterien ableiten

6:07 Kommen wir zum direktesten Weg zu aussagekräftigen Tests — und er führt zurück zu Modul vier. Denn die Akzeptanzkriterien, die Sie dort formuliert haben, sind bereits Testfälle. Man muss sie nur übersetzen. Und die Reihenfolge, in der das passiert, entscheidet über alles Weitere. Zusätzliche Arbeit kostet das übrigens nicht — die Vorarbeit haben Sie längst geleistet.

6:30 Jedes überprüfbar formulierte Kriterium ist bereits ein Testfall, und die Beispiele und Gegenbeispiele sind seine Daten. Das hat einen Nebeneffekt, der die Mühe allein rechtfertigt: Wenn sich ein Kriterium nicht in einen Test übersetzen lässt, war es nicht überprüfbar formuliert. Und das merken Sie jetzt, bevor Code entsteht, statt bei der Abnahme.

6:50 Die Übersetzung ist damit gleichzeitig eine Qualitätsprüfung Ihrer eigenen Anforderung — kostenlos und ziemlich unbestechlich. Damit ist die Übersetzung mehr als Fleißarbeit: Sie prüft rückwirkend die Qualität Ihrer eigenen Formulierung. Zwei Zeilen, und der Unterschied ist folgenreich. Wird der Test aus dem Akzeptanzkriterium abgeleitet, prüft er die Anforderung. Das ist der Sollfall, und er trägt kein Risiko.

7:15 Wird er aus fertigem Code abgeleitet, prüft er die Umsetzung — und bestätigt damit auch jedes Missverständnis, das in die Umsetzung eingeflossen ist. Der Test wird grün, der Fehler bleibt, und ab jetzt ist er zusätzlich noch festgeschrieben. Und genau der zweite Fall tritt ein, wenn man einem Agenten fertigen Code vorlegt und um Tests bittet. Das ist die häufigste Art, wie Tests entstehen.

7:38 Der erste Punkt ist der eben beschriebene und der verbreitetste überhaupt: erst bauen lassen, dann um Tests bitten. Der zweite ist subtiler — ein Kriterium für überprüfbar halten, ohne es einmal übersetzt zu haben. Die Übersetzung ist der Test der Überprüfbarkeit, nicht das Gefühl. Der dritte ist eine verschenkte Gelegenheit: Die Gegenbeispiele aus Modul vier sind fertige Testdaten, sie liegen schon da.

8:02 Und der vierte: Tests und Umsetzung im selben Auftrag erzeugen lassen — dann prüft niemand mehr, ob der Test je gegriffen hätte.

Test-first, Test-after und Characterization Tests

8:10 Jetzt zu einer Frage, die oft als Glaubensfrage geführt wird und keine ist. Test-first oder Test-after — darüber lässt sich lange streiten. Es lohnt sich nicht, weil die drei Vorgehensweisen klar getrennte Einsatzfelder haben. Wer sie kennt, muss nicht mehr streiten, sondern kann im Einzelfall wählen. Und die dritte Vorgehensweise ist die, mit der Sie im Bestand überhaupt erst arbeiten können.

8:35 Drei Zeilen, drei Situationen. Test-first passt, wenn das gewünschte Verhalten bekannt und der Code neu ist. Der Test ist dann eine ausführbare Spezifikation — und er hat bei agentischer Arbeit einen zusätzlichen Nutzen, den man selten hört: Er schützt davor, dass der Agent die Anforderung unterwegs umdeutet. Test-after ist der Normalfall bei explorativer Arbeit, trägt aber das bekannte Risiko, die Umsetzung festzuschreiben.

9:00 Und Characterization Tests beschreiben, was ein bestehendes System heute tut, ohne zu behaupten, dass es richtig ist. Der Begriff stammt von Michael Feathers, aus dem Klassiker über Legacy Code. Diese Unterscheidung ist wichtiger, als sie klingt. Ein Characterization Test billigt das Verhalten nicht — er hält es fest. Aus einem unbekannten Verhalten wird ein festgehaltenes. Und erst dieses festgehaltene Verhalten lässt sich absichtlich ändern statt versehentlich. Das ist die ganze Idee.

9:29 Wenn Ihnen beim Charakterisieren etwas fachlich falsch vorkommt, halten Sie es trotzdem zunächst fest — vielleicht verlässt sich jemand darauf. Die Korrektur ist eine eigene Entscheidung mit eigenem Auftrag, und sie kommt danach.

Typische Schwächen KI-generierter Tests

9:42 Und jetzt zum praktisch nützlichsten Kapitel dieses Moduls. Erzeugte Tests haben ein wiederkehrendes Fehlerprofil, und weil es wiederkehrend ist, können Sie es gezielt abfragen. Am Ende steht eine Gegenprobe, die zwei Minuten kostet und erstaunlich viel aussagt — und die ein sehr großes Vorbild hat. Sie ist zugleich das nützlichste Werkzeug, das dieses Modul zu bieten hat.

10:05 Vier Muster, die Sie wiedererkennen werden. Erstens bestätigen erzeugte Tests die Implementierung, weil sie aus ihr abgeleitet wurden — ein Test, der einen Fehler mit abbildet, ist grün und wertlos. Zweitens fehlen Feststellungen: Der Ablauf läuft durch, geprüft wird nichts. Drittens wird zu viel durch Attrappen ersetzt, bis am Ende nur noch die Attrappen geprüft werden.

10:26 Und viertens klammern sich die Tests an Interna, sodass jedes Refactoring sie bricht, obwohl sich das Verhalten gar nicht geändert hat. Die Gegenprobe ist simpel: Verändern Sie drei Zeilen im Code absichtlich fehlerhaft und zählen Sie, was rot wird. Das klingt nach Bastelei — und ist in Wirklichkeit ein etabliertes Verfahren, das Mutationstesten heißt.

10:47 Rechts sehen Sie, in welchem Maßstab: Google setzt es im Review-Ablauf von über vierundzwanzigtausend Entwicklern in über tausend Projekten ein. Interessant ist die dritte Zeile, denn dort steht die Haltung dahinter: Vollständigkeit ist ausdrücklich nicht das Ziel. Die Autoren halten Mutationsvollständigkeit für weder praktikabel noch wünschenswert. Es geht um handlungsrelevante Einzelbefunde, nicht um eine vollständige Messung.

11:12 Wenn Sie sich einen Satz aus diesem Modul merken, dann diesen: Welche Zeile im Code kann ich verändern, ohne dass ein Test rot wird? Diese Frage beantwortet in zwei Minuten, was eine Abdeckungszahl nie beantwortet. Denn abgedeckte Fälle sind die im Code sichtbaren — und genau die interessanten Fälle sind die, an die niemand gedacht hat.

11:31 Bemerkenswert finde ich, dass Google beim eigenen Verfahren dieselbe Zurückhaltung übt, die wir gleich bei der Abdeckungsquote sehen werden: Nicht die Vollständigkeit der Messung zählt, sondern die Brauchbarkeit des einzelnen Befunds.

Das Nachweisprinzip beim Regressionstest

11:44 Zum letzten fachlichen Kapitel — und es enthält eine Regel, die jede Diskussion über Fehlerkorrekturen abkürzt. Sie ist kurz, sie klingt pedantisch, und sie ist unter agentischer Arbeit doppelt wichtig geworden. Der Grund dafür liegt in der Art, wie Test und Korrektur heute entstehen. Wer sie einhält, spart sich jede weitere Diskussion über die Güte einer Fehlerkorrektur.

12:07 Die Regel lautet: Der Test zum Fehler muss vor der Korrektur fehlschlagen. Ein Regressionstest, der nie rot war, belegt nichts — und zwar in dreifacher Hinsicht. Er belegt nicht, dass er den Fehler überhaupt trifft. Er belegt nicht, dass die Korrektur wirkt. Und er belegt nicht einmal, dass er ausgeführt wird; vielleicht ist er falsch benannt und läuft gar nicht mit.

12:28 Alle drei Zweifel verschwinden in dem Moment, in dem Sie den roten Balken einmal gesehen haben. Fünf Schritte, und die Reihenfolge ist der ganze Inhalt. Erst den Fehler als Test festhalten. Dann laufen lassen und den roten Balken tatsächlich sehen — nicht annehmen, sehen. Dann korrigieren. Dann den grünen sehen. Und der fünfte Schritt ist der für agentische Arbeit entscheidende: Verlangen Sie im Auftrag den fehlgeschlagenen Lauf als Nachweis, nicht die Behauptung, es habe einen gegeben.

12:57 Denn wenn Test und Korrektur im selben Durchgang entstehen, sieht hinterher niemand mehr, ob der Test je gegriffen hätte. Der erste Punkt ist der zentrale und passiert bei agentischer Arbeit fast automatisch: Test und Korrektur zusammen beauftragen und den roten Lauf nie sehen. Der zweite ist die bequeme Variante — die Zusicherung des Agenten annehmen. Der dritte ist der stille Fehler: ein Regressionstest, der auch ohne Korrektur grün wäre.

13:24 Der kommt häufiger vor, als man denkt, und fällt nie auf. Und der vierte ist die Umkehrung der Reihenfolge: erst korrigieren, dann den Test passend formulieren. Dann beschreibt er die Lösung statt den Fehler.

Übung: Einen KI-Testsatz fachlich bewerten

13:37 Zum Abschluss eine Übung, in der die Testsuite selbst auf den Prüfstand kommt. Sie bekommen die Doppelbuchungsprüfung des Fahrtenbuchs samt einem vollständig erzeugten Testsatz, der grün durchläuft. Grün heißt hier ausdrücklich nicht geprüft — und genau das sollen Sie zeigen. Wir wenden dabei alles an, was in diesem Modul dazugekommen ist.

13:57 Beurteilen Sie den Testsatz nicht an der Zahl der Tests, sondern an den Aussagen: Welche fachliche Regel wird tatsächlich belegt, welche nur scheinbar? Suchen Sie gezielt nach den Schwächen aus diesem Modul — Sie wissen jetzt, wonach. Dann kommt die Gegenprobe: Verändern Sie die Implementierung an drei Stellen absichtlich fehlerhaft und stellen Sie fest, welche dieser Änderungen die Suite bemerkt.

14:20 Und ergänzen Sie zum Schluss die fehlenden Grenzfälle. Der Werkstatttermin fehlt fast immer — die Überschneidung, die zulässig ist. Fünf Schritte in gut einer Stunde. Die Schritte drei und vier sind der Kern, und sie sind nichts anderes als Mutationstesten von Hand — dieselbe Idee, die Google industrialisiert hat, nur mit drei statt Millionen Mutanten.

14:40 Sie werden dabei vermutlich feststellen, dass ein Teil der Tests keine der drei Änderungen bemerkt. Das ist kein Zeichen für einen besonders schlechten Testsatz, sondern der Normalfall bei aus Code abgeleiteten Tests. Und es ist der Grund, warum wir dieses Modul überhaupt haben.