Der Ablauf wirkt vernünftig: Du lässt dir eine Funktion bauen, überfliegst sie — und weil du gründlich sein willst, bittest du denselben Agenten um Tests dazu. Zehn Sekunden später sind sie grün. Nur belegen sie nichts.
Aus Code abgeleitete Tests prüfen die Umsetzung, nicht die Anforderung
Ein Test, der aus fertigem Code entsteht, beschreibt genau das, was der Code tut. Steckt darin ein Missverständnis der Aufgabe, wird es mit festgeschrieben — und ist ab jetzt durch eine grüne Suite gedeckt. Das ist die unangenehmste Variante: Der Fehler ist nicht mehr nur da, er gilt jetzt als geprüft.
Wer eine Funktion selbst schreibt, hat über jeden Zweig nachgedacht. Wer sie liest, hat nur einen Eindruck — und das Auge liest über Randfälle hinweg.
Das Akzeptanzkriterium ist schon der Testfall
Die Gegenrichtung kostet nichts: Jedes überprüfbar formulierte Kriterium ist bereits ein Testfall, Beispiele und Gegenbeispiele sind seine Daten. Lässt es sich nicht in einen Test übersetzen, war es nicht überprüfbar formuliert — und das merkst du jetzt statt bei der Abnahme.
Der rote Balken ist der Beleg
Für Fehlerkorrekturen gilt eine Regel, die jede Diskussion abkürzt: Der Test zum Fehler muss vor der Korrektur fehlschlagen, und du musst den roten Lauf gesehen haben. Sonst ist offen, ob er den Fehler trifft — oder ob er je ausgeführt wird. Genau das geht verloren, wenn Test und Korrektur im selben Auftrag entstehen. Verlange den fehlgeschlagenen Lauf, nicht die Zusicherung.
Mehr dazu im Seminar
Wie du Testziele statt Testmengen beauftragst, zeigt das Modul Teststrategie für KI-generierten Code aus dem Seminar Clean Code und KI-gestützte Entwicklung — mit Video und Kapitelübersicht.