KI-generierten Code testen: mit unabhängigen End-to-End-Tests

Was es heißt, KI-generierten Code zu testen

KI-generierten Code zu testen heißt zu beweisen, dass Ihre Anwendung immer noch tut, was ihre Nutzer brauchen, nachdem ein KI-Programmieragent sie geändert hat.Wer die Zeilen geschrieben hat, ist dem Nutzer egal.Es zählt, ob die Anmeldung noch funktioniert, ob die Gesamtsumme noch stimmt und ob die Schaltfläche noch da ist.

Programmieragenten tun heute weit mehr, als eine Zeile zu vervollständigen.Claude Code, Cursor, GitHub Copilot, OpenAI Codex und Devin können eine Aufgabe übernehmen, viele Dateien ändern, Befehle ausführen und einen Pull-Request öffnen.Manche Teams gehen weiter und praktizieren Vibe Coding: Sie beschreiben, was sie wollen, übernehmen, was zurückkommt, und lesen den Code kaum noch.

Der Code kommt inzwischen schneller, als ihn jemand prüfen kann.Ein Reviewer bekommt einen Diff von Hunderten Zeilen in einem Dutzend Dateien, und ein Diff zeigt nie die laufende Anwendung.Beim Testen in der agentischen Entwicklung geht es darum, diese Lücke zu schließen: eine Prüfung der fertigen Anwendung, die nicht davon abhängt, den Code zu lesen.

Warum die eigenen Tests des Agenten nicht genügen

Der erste Gedanke ist, den Agenten auch Tests schreiben zu lassen.Tun Sie das: Unit-Tests fangen echte Fehler ab, und ein Agent schreibt sie schnell.Aber ein Test vom selben Agenten, der den Code geschrieben hat, teilt dessen Verständnis der Aufgabe.Hat der Agent die Anforderung falsch verstanden, stimmen Code und Test miteinander überein, und beide sind falsch.

Tests auf Codeebene haben mehr blinde Flecken als eine falsch verstandene Anforderung.

Diese blinden Flecken haben eines gemeinsam: Sie sind aus dem Inneren des Codes unsichtbar.Der Beweis muss von außen kommen, von der laufenden Anwendung, so gesehen, wie ein Nutzer sie sieht.

Lösen selbstheilende End-to-End-Tests das Problem?

End-to-End-Tests sind die klassische Antwort.Ein End-to-End-Test bedient die echte Anwendung über ihre Oberfläche, so wie ein Nutzer es tut, und prüft, was geschieht.Die meisten Teams schreiben sie als Code, mit Playwright, Cypress oder Selenium: Sie schreiben einen Selektor für jedes Element und eine Codezeile für jeden Klick.

Agenten schreiben diesen Code gut, und die Werkzeuge helfen ihnen inzwischen dabei.Playwright liefert Testagenten mit: einen Planer, einen Generator und einen Healer, der einen fehlschlagenden Test erneut abspielt, die Seite untersucht und den Test so lange anpasst, bis er besteht, oder ihn als übersprungen markiert, wenn er die Funktion für defekt hält.Bei Cypress verwandelt cy.prompt Schritte in einfachem Englisch in Cypress-Befehle und heilt einen Schritt, wenn sich sein Selektor oder sein Text zwischen zwei Läufen ändert.Mit Playwright MCP steuert ein Agent einen Browser über die Barrierefreiheits-Snapshots der Seite.

Selbstheilung ist nützlich, denn hinter den meisten kaputten End-to-End-Tests steckt ein umbenannter Selektor, kein Bug.Das Risiko entsteht, wenn ein einziger Agent alles tut: Er schreibt die Funktion, schreibt den Test und repariert den Test, wenn er fehlschlägt.Jede Reparatur ist für sich genommen vernünftig.Zusammen können sie den Test von dem, was der Nutzer braucht, zu dem verschieben, was der Code zufällig tut.

Um die Werkzeuge für End-to-End-Tests selbst zu vergleichen, lesen Sie die Vergleichsstudie.

Wie testen Sie KI-generierten Code mit End-to-End-Tests?

Sechs Gewohnheiten machen End-to-End-Tests zu einer Leitplanke, um die sich ein Agent nicht herumreden kann.Keine davon braucht ein bestimmtes Werkzeug.

1. 1

   Die Abläufe aufschreiben, die nie kaputtgehen dürfen

   Listen Sie die fünf bis zehn Abläufe auf, ohne die Ihre Nutzer nicht auskommen: registrieren, anmelden, suchen, in den Warenkorb legen, bezahlen, einen Bericht exportieren.Schreiben Sie jeden so auf, wie Sie ihn einem neuen Tester erklären würden, mit seinem erwarteten Ergebnis.Diese Liste ist Ihre Spezifikation, und sie gehört Ihnen, nicht dem Agenten.

2. 2

   Den Test erstellen, bevor der Agent den Code schreibt

   Ist ein Ablauf neu, erstellen Sie zuerst seinen End-to-End-Test, aus dem Design oder aus den Schritten.Der Agent arbeitet dann auf ein Ziel hin, das er nicht selbst gewählt hat.Der Test schlägt fehl, solange die Funktion nicht läuft: testgetriebene Entwicklung, angewandt auf Agenten.

3. 3

   Prüfen, was der Nutzer sieht

   Prüfen Sie den Bildschirm: die Wörter, die ein Nutzer liest, das Aussehen eines Elements, die Anordnung der Dinge.Vermeiden Sie Prüfungen interner IDs, Klassennamen und Zustände, die nur der Code kennt, denn genau diese ändert ein Agent nach Belieben.Ein Test, der am Bildschirm verankert ist, übersteht ein Neuschreiben des Codes darunter.

4. 4

   Die Tests außer Reichweite des Agenten halten

   Legen Sie die Tests neben dem Code ab, aber sorgen Sie dafür, dass jede Änderung an ihnen ein Review durch einen Menschen erfordert.Auf GitHub leistet genau das ein CODEOWNERS-Eintrag für den Testordner, wenn vor einem Merge die Freigabe durch die Code Owner verlangt wird.Der Agent darf die Tests ausführen und eine Änderung an einem von ihnen vorschlagen.Diese Änderung mergt er nie allein.

5. 5

   Die Tests bei jedem Pull-Request ausführen

   Führen Sie die End-to-End-Regressionstests bei jedem Pull-Request aus, den der Agent öffnet, auf einem Rechner, der die echte Anwendung zeigt, und lassen Sie einen Fehlschlag den Merge blockieren.Ein Ergebnis, das nur warnt, wird bald ignoriert.Was Läufe jedes Mal bestehen lässt, von einer festen Bildschirmgröße bis zu einem bekannten Ausgangszustand, steht in Einen Test ausführen.

6. 6

   Fehlschläge für den Agenten und für Sie lesbar machen

   Ein fehlgeschlagener Test sollte sagen, was fehlgeschlagen ist, wo, und wie der Bildschirm vom Erwarteten abweicht, mit Bildern.Der Agent nutzt das, um eine Korrektur vorzuschlagen.Sie nutzen es, um zu entscheiden, ob die Änderung ein Bug oder gewollt war.

Wo der Mensch im Kreislauf bleibt

„Human in the Loop“ bedeutet nicht, dass ein Mensch jede Codezeile liest.Es bedeutet, dass ein Mensch die Entscheidungen verantwortet, die der Code nicht selbst treffen kann.

KI-Werkzeuge für Code-Reviews helfen bei der zweiten Zeile: Sie lesen einen Diff und weisen auf riskanten Code hin.Dennoch schauen sie auf den Code, nicht auf die laufende Anwendung.Der End-to-End-Lauf ist die einzige Prüfung, die auf das Produkt schaut.

End-to-End-Tests für KI-Programmieragenten mit GUI Test Studio

GUI Test Studio wurde für diese Rollenteilung gebaut.Ein Mensch zeichnet den Test auf oder beschreibt ihn, der Agent führt ihn aus und liest das Ergebnis, die Pipeline führt ihn bei jedem Build aus, und eine Änderung dessen, was der Test erwartet, wartet auf einen Menschen.

Ein Test, der nicht vom Code abhängt

Zeichnen Sie den Ablauf einmal im GUI Test Runner-Recorder auf, indem Sie sich durch die echte Anwendung klicken und tippen, oder beschreiben Sie ihn in einem Prompt für Claude, ChatGPT oder ein lokales KI-Modell auf Ihrem eigenen Computer, eines von uns oder Ihr eigenes.So oder so prüft der Test den Bildschirm.Eine Bild-Assertion vergleicht das Bild eines Elements, eine Text-Assertion liest seine Wörter, eine Layout-Assertion prüft, wie Elemente angeordnet sind.

Es gibt keinen Selektor zu schreiben und keinen Testcode, den der Agent umschreiben könnte.Die GTS Engine + AI findet jedes Element über das, was die Anwendung darüber sagt, ihre Barrierefreiheitsinformationen, und am Aussehen, wenn sie nichts sagt.Eine umbenannte Klasse oder eine neu geschriebene Komponente macht den Test nicht kaputt.Wenn ein Assistent einen Test für Sie erstellt, wird jede Prüfung, die er hinzufügt, an Ort und Stelle ausprobiert und abgelehnt, wenn sie auf dem Bildschirm jetzt gerade nicht bestehen könnte.

Der Agent führt ihn aus und liest das Ergebnis

GUI Test Studio bringt einen MCP-Connector mit, sodass der Assistent, der Ihren Code schreibt, auch Ihre Tests ausführen kann.Er funktioniert mit Claude Code, Claude Desktop, ChatGPT mit Codex und Copilot Chat in VS Code, jeweils mit einem Klick verbunden, und mit jedem anderen Assistenten, der einen MCP-Connector annimmt.

Run the Checkout test and tell me what failed.

Ein fehlgeschlagener Lauf wird anhand seines Berichts erklärt und nie mit einer neuen Aufzeichnung des Tests beantwortet, es sei denn, Sie verlangen das.Über den Connector bleibt der Test, der die Änderung des Agenten beurteilt, derjenige, den Sie freigegeben haben, bis Sie eine Änderung an ihm bestätigen.

Bei jedem Pull-Request, mit gtr-cli

gtr-cli führt dieselben Tests aus Ihrer Pipeline aus, auf einem Windows-Build-Rechner, und antwortet so, wie eine Pipeline es erwartet.Sein Exitcode lässt den Build fehlschlagen, eine JUnit-Datei füllt die Registerkarte der Tests, eine JSON-Datei steht für ein Skript oder einen Agenten bereit, und eine Markdown-Zusammenfassung liegt für den Pull-Request bereit.Ein Lauf mit gtr-cli ändert die Testdatei nie.

gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
  --json results\run.json --summary results\summary.md --artifacts results\artifacts ^
  --jira on-failure

Mit --jira on-failure wird ein fehlgeschlagener Test zu einem Jira-Vorgang mit den Schritten zur Reproduktion und dem erwarteten und dem gefundenen Bild, und tritt derselbe Fehlschlag erneut auf, kommt ein Kommentar hinzu statt eines Duplikats.Derselbe Befehl funktioniert in GitHub Actions, GitLab, Azure DevOps, Jenkins und TeamCity: siehe Tests in Ihrer Pipeline ausführen, und End-to-End-Tests bei jedem Build ausführen für eine Schritt-für-Schritt-Einrichtung mit TeamCity.

Ein zweiter Blick, und das letzte Wort hat ein Mensch

Jeder Lauf endet in einem Konfidenzbericht, der für jede Prüfung sagt, ob das Element gefunden wurde und ob es dem Aufgezeichneten entspricht.Scheitert eine Prüfung an Pixeln, kann die Intelligente KI-Analyse einen zweiten Blick darauf werfen: Sie ignoriert harmloses Rendering-Rauschen und erkennt trotzdem echte Regressionen, etwa ein geändertes Wort, ein fehlendes Badge oder eine grau gewordene Schaltfläche.Ist sie eingeschaltet, ist ihre Antwort das endgültige Ergebnis dieser Prüfung, mit dem, was sich geändert hat, in einfachen Worten.Sie läuft in der Cloud mit Ihrem eigenen OpenAI- oder Anthropic-Schlüssel oder mit einem lokalen KI-Modell auf Ihrem eigenen Computer: einem von uns, oder Ihrem eigenen.

Vergrößern

Hat sich die Anwendung absichtlich geändert, übernimmt ein Mensch das neue Aussehen im Bericht und speichert es, und der Test erwartet es von nun an.Wie Sie den Bericht lesen, steht in Den Konfidenzbericht lesen.

Dieser Leitfaden ist die praktische Seite des Testens.Für den ganzen Zyklus der Entwicklung mit KI-Agenten, vom Prompt bis zum Jira-Bug, den der Agent behebt, lesen Sie Entwicklung mit KI-Agenten (ADLC).

Fragen

Claude, Cursor, GitHub Copilot, OpenAI Codex, ChatGPT, Devin, Playwright, Cypress, Selenium, Jira und TeamCity sind Marken ihrer jeweiligen Inhaber.