Software zu testen, die man nicht entworfen hat, bedeutet, das mentale Modell des Autors nicht zu kennen. Bei KI-generiertem Code gab es keinen menschlichen Autor, sodass dieses Modell möglicherweise gar nicht existiert. Die praktische Konsequenz ist, dass Coverage-Metriken als Proxy für Vertrauen unzuverlässig werden.
Warum Coverage hier irreführt
Zeilen- und Branch-Coverage zeigen Ihnen, welcher Code während der Tests ausgeführt wurde. Sie sagen nichts darüber aus, ob die Tests dazu geschrieben wurden, das richtige Verhalten zu prüfen. Wenn ein Modell sowohl die Implementierung als auch die Testsuite generiert, tendieren die Tests dazu, dieselben Annahmen widerzuspiegeln, die den Code geprägt haben. Lücken im Verständnis des Modells tauchen an beiden Stellen gleichzeitig auf, sodass die Coverage-Werte gesund aussehen, während relevante Szenarien ungetestet bleiben.
Dies ist kein theoretisches Risiko. KI-Modelle generieren plausibel wirkenden Code. Plausibel und korrekt sind nicht dasselbe, und ein Test, der von demselben Modell geschrieben wurde, das auch die Funktion geschrieben hat, wird den Unterschied kaum aufdecken.
Was stattdessen zu tun ist
Der Wandel besteht darin, von der Messung der Ausführung zum Nachdenken über das Verhalten überzugehen.
Beginnen Sie mit der Spezifikation, nicht mit dem Code. Schreiben Sie Tests auf Basis von Anforderungen oder erwartetem Verhalten, bevor Sie die Implementierung lesen. Falls keine Spezifikation existiert, schreiben Sie eine, auch kurz gefasst, bevor Sie die generierte Datei öffnen. Das verhindert, dass der Code Ihre Erwartungen beeinflusst.
Testen Sie die Grenzfälle, die das Modell wahrscheinlich nicht berücksichtigt hat. Modelle behandeln den Happy Path in der Regel gut. Grenzfälle mit leeren Eingaben, gleichzeitigen Schreibzugriffen, Locale-Unterschieden, Integer-Überlauf oder fehlenden Berechtigungen sind eher lückenhaft abgedeckt. Erfassen Sie diese unabhängig davon.
Verwenden Sie Property-based Testing, wo es sinnvoll ist. Anstatt spezifische Ausgaben zu prüfen, prüfen Sie Invarianten: Eine Sortierfunktion sollte immer eine Liste gleicher Länge zurückgeben; eine Preisfunktion sollte nie einen negativen Wert zurückgeben. Property-based-Tools generieren automatisch Hunderte von Eingaben und legen Annahmen offen, die das Modell stillschweigend eingebaut hat.
Lesen Sie den Code mit Blick auf die Absicht, nicht nur auf die Korrektheit. Bevor Sie der Testsuite vertrauen, verfolgen Sie die Implementierung und fragen Sie sich, wofür der Code optimiert ist. KI-generierter Code löst manchmal ein leicht anderes Problem als das genannte, insbesondere wenn der Prompt mehrdeutig war. Das tatsächliche Verhalten zu verstehen, anstatt des beabsichtigten Verhaltens, verändert, was Sie testen.
Behandeln Sie externe Aufrufe mit besonderer Skepsis. Generierter Code, der APIs, Datenbanken oder Queues aufruft, mockt diese Abhängigkeiten in Tests häufig. Prüfen Sie, ob die Mocks das tatsächliche Verhalten der echten Abhängigkeit widerspiegeln, einschließlich Fehlerzuständen und Rate Limits, und nicht nur den Erfolgsfall.
Die Frage nach dem Vertrauen
Coverage ist ein Proxy für Vertrauen, weil bei Code, den ein Mensch geschrieben hat, die Person, die ihn geschrieben hat, die Tests in der Regel auch so konzipiert hat, dass sie die Dinge abfangen, über die sie sich Gedanken gemacht hat. Diese Beziehung bricht zusammen, wenn Code und Tests einen gemeinsamen automatisierten Ursprung haben.
Vertrauen in KI-generierten Code muss aus einer anderen Quelle kommen: aus dem Verständnis, was der Code tut, aus Tests, die gegen die Spezifikation statt gegen die Implementierung geschrieben wurden, und aus systematischer Aufmerksamkeit gegenüber den Fehlerkategorien, die Modelle zuverlässig unterschätzen.
Das Thema hängt mit der größeren Frage zusammen, wie man KI-generierten Code reviewt. Code-Review und Testen sind verschiedene Tätigkeiten. Hat der Code keinen menschlichen Entwerfer, müssen sie sich jedoch stärker ausgleichen als sonst. Wer nur einen Linter laufen lässt und die Coverage prüft, ist dafür nicht gerüstet.
Es hängt auch damit zusammen, was sich am Code Review grundsätzlich verändert hat. Der reviewende Engineer ist nun die primäre Quelle des Design-Urteils, nicht nur ein Genehmiger der Arbeit anderer.
Was wir prüfen
Drei unserer Scorecard-Kriterien sprechen dies direkt an. Die Verifizierung von KI-Output bewertet, ob ein Engineer halluzinierte APIs, subtil fehlerhafte Logik oder Sicherheitslücken erkennt, bevor generierter Code ausgeliefert wird. Risikoorientiertes Urteilsvermögen prüft, ob der Review-Aufwand mit der Konsequenz skaliert – nicht damit, wie sicher der Agent klang. Eigenverantwortung umfasst Tests, Observability und Debugging nach dem Release, unabhängig davon, wer den Code geschrieben hat. Beide Sitzungen testen dies unter realistischen Bedingungen, mit und ohne KI-Tools. Siehe how we vet.
Kurze Antworten
Warum reicht 100 % Testabdeckung bei KI-generiertem Code nicht aus?
Testabdeckung misst, welche Zeilen ausgeführt wurden, nicht, ob die richtigen Fragen gestellt wurden. Wenn dasselbe Modell sowohl den Code als auch die Tests schreibt, teilen beide dieselben blinden Flecken. Hohe Abdeckung kann daher gleichzeitig mit großen, nicht getesteten Verhaltensbereichen bestehen.
Sollte man Tests schreiben, bevor oder nachdem man KI-generierten Code gelesen hat?
Möglichst vorher. Wer zuerst die Implementierung liest, richtet seine Erwartungen an dem aus, was das Modell produziert hat. Wer Tests zunächst anhand der Spezifikation schreibt, definiert das korrekte Verhalten unabhängig davon, das bringt Abweichungen zuverlässiger ans Licht.
Welche Arten von Fehlern übersehen KI-generierte Tests am häufigsten?
Randfälle mit leeren oder fehlerhaften Eingaben, gleichzeitige Zugriffe, Ausfälle externer Abhängigkeiten, Sensitivität gegenüber Locale oder Zeitzone sowie Berechtigungsgrenzen. Modelle optimieren für den Normalfall; systematische Tests müssen die Fälle abdecken, die unwahrscheinlich, aber folgenreich sind.
