Kann ich die KI Tests für ihren eigenen Code schreiben lassen?
Ja, aber nicht mit „schreib Tests für diesen Code". Dann liest der Agent den Code und bestätigt, was er tut, inklusive aller Bugs. Stattdessen die Spezifikation in den Prompt geben, mit konkreten Beispiel-Zahlen. Tests prüfen, was der Code SOLL, nicht was er tut.
Die Idee liegt nahe: Der Agent hat den Code geschrieben, also soll er ihn auch testen. Das funktioniert, aber nur mit der richtigen Reihenfolge. Mit der falschen bekommst du Tests, die wertlos sind und Sicherheit vortäuschen.
Das Spiegel-Problem
Wer dem Agenten den Code zeigt und „teste das" sagt, bekommt einen Spiegel: Der Agent liest die Implementierung und schreibt Tests, die genau bestätigen, was der Code tut. Hat der Code einen Bug, zementiert der Test den Bug als korrektes Verhalten. Die Forschung nennt das Implementation-Mirroring, eine der drei dokumentierten Schwächen KI-generierter Tests, neben übermäßigem Mocking und Behauptungen, die nichts prüfen.
Die Lösung: Spec statt Code
Der Test-Prompt enthält die Spezifikation und konkrete Beispiel-Cases mit echten Zahlen, nicht den Code:
Statt: „Schreib Tests für meine Budget-Funktion." Besser: „Test against this spec: status is ok below 80%, warning from 80 to 100%, over above 100%. Example: budget 50000, spent exactly 40000 → warning (the boundary belongs to warning)."
Die Beispiel-Zahlen verankern, was richtig bedeutet, unabhängig davon, was die Implementierung gerade tut. Zwei weitere Zeilen mit messbarer Wirkung: „Test behavior, assert on returned values" und „avoid mocks".
Die wichtigste Regel am Ende
„If any test fails against the current implementation, report the failures. Do NOT adjust the tests to make them pass." Ein fehlschlagender Test gegen die Spec heißt: Der Code ist falsch, nicht der Test. Wer noch einen Schritt weiter will, lässt die Tests VOR der Implementierung schreiben und committet sie separat. Dann ist jede spätere Test-Manipulation im Diff sichtbar.