Wo das Testen in der KI-Webentwicklung hinsehen muss
| Zustand zwischen den Schritten | Ein Formular wird abgeschickt, und die Liste dahinter aktualisiert sich nicht. Ein Filter überlebt bis in eine Ansicht, in der er keinen Sinn mehr ergibt. |
| Timing | Rendering vor den Daten, oder eine Anfrage, die erst zurückkommt, wenn die Komponente nicht mehr da ist. |
| Der zweite Nutzer | Eigentümerschaft und Sichtbarkeit, abgeleitet aus der Session, in der das Feature entstanden ist. |
Nichts davon ist in einem Diff sichtbar – deshalb hilft ein schnelleres Review nicht. Sichtbar wird es in dreißig Sekunden mit der laufenden Anwendung – deshalb muss die Prüfung genau dort stattfinden.
Warum die Tests, die der Agent geschrieben hat, den Zyklus nicht schließen
Tests, die zusammen mit der Implementierung entstehen, teilen deren Annahmen. Wenn der Code davon ausgeht, dass ein Endpunkt ein leeres Array statt eines 404 zurückgibt, prüft der Test genau diese Annahme und läuft durch. Sie bekommen Abdeckung, aber kein unabhängiges Signal.
Die Prüfung, die den Zyklus schließt, muss das ausgelieferte Produkt gegen das beabsichtigte Verhalten testen – nicht gegen die Vorstellung, die der Code von sich selbst hat.
Schnell genug, um es wirklich einzusetzen
Ein Verifizierungsschritt, der länger dauert als der Bau des Features, wird übersprungen – zu Recht. Drei Dinge halten den Aufwand im Verhältnis: Flows statt Screens abdecken, Ketten kurz halten und beim Pull Request laufen lassen statt bei jedem Speichern.
Den Zyklus eng genug halten, damit er auch genutzt wird
Ein Verifizierungsschritt, der sich langsam anfühlt, wird übersprungen, und dieses Überspringen ist rational – das Tempo zählt also genauso viel wie die Abdeckung.
Drei Dinge halten den Aufwand im Verhältnis. Decken Sie Flows ab statt Screens, denn ein Flow ist eine Prüfung und ein Screen sind fünf. Halten Sie jeden Flow auf dem kürzesten Pfad, der einen echten Bruch noch findet – meist drei oder vier Schritte statt zehn. Und lassen Sie die breite Suite beim Pull Request laufen, während ein oder zwei Prüfungen schnell genug bleiben, um während der Arbeit selbst zu laufen.
Diese letzte Trennung wird am häufigsten übersehen. Die Prüfung, die Sie beim Bauen laufen lassen, und die Prüfung, die den Merge absichert, haben unterschiedliche Aufgaben. Wer beides mit einer einzigen Suite erledigen will, bekommt sie entweder zu langsam für häufige Läufe oder zu dünn, um ihr zu vertrauen.
So kommt es in den Zyklus
Das Setup installiert den Verifizierungs-Skill in den Coding-Agenten, sodass die Prüfung dort stattfindet, wo auch die Arbeit stattfindet – und nicht als separate Pflichtübung.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie lieber nichts installieren möchten: Das Dashboard leistet dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.
Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Sie lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt – an Ihrem Repository ändert sich also nichts.
GitHub Actions bringt den Schritt in Ihren eigenen Workflow, konfiguriert vom Terminal aus.
Was TestSprite verifiziert und der Agent nicht kann
Die ausgelieferte Anwendung – gegen das, was laut Ihrer Vorgabe passieren soll, nicht gegen das, was der Code annimmt. Genau um diese Unabhängigkeit geht es: Tests, die neben der Implementierung entstehen, teilen deren Annahmen und stimmen ihr deshalb auch dort zu, wo beide falsch liegen.
Das Setup installiert den Verifizierungs-Skill in Ihren Coding-Agenten, sodass die Prüfung Teil der Änderung selbst wird. Schritte sind Absichten statt Selektoren, und ein Fehlschlag kommt als ein Paket zurück, mit dem der Agent arbeiten kann – so bleibt die Korrektur im selben Zyklus wie die Änderung.
Sie bekommen damit Zustands-, Timing- und Zweitnutzer-Fehler, die vor dem Merge gefunden werden statt von einem Nutzer, und das ohne einen Verifizierungsschritt, der länger dauert als das Feature selbst.
Bremst das die Entwicklung?
Weniger als das Debugging, das es verhindert. Der Vergleich läuft nicht gegen null Aufwand, sondern dagegen, denselben Fehler nach dem Release zu finden.
Kann der Agent seine eigene Arbeit testen?
Er kann die Prüfungen ausführen. Die Prüfungen selbst müssen aus dem beabsichtigten Verhalten stammen und nicht aus der Implementierung – sonst benoten Sie Ihre eigenen Hausaufgaben.
Und was ist mit den Tests, die er generiert hat?
Behalten Sie sie für die Abdeckung, und behandeln Sie sie nicht als unabhängige Verifizierung. Sie stimmen dem Code schon von ihrer Konstruktion her zu.
Wie viel Abdeckung braucht es vor dem Release?
Die Flows, bei denen ein Bruch Ihnen peinlich wäre, dazu alles, was Geld oder Berechtigungen berührt. Erweitern Sie ausgehend von echten Vorfällen.
Funktioniert das auch bei lokaler Entwicklung?
Frontend-Läufe erreichen über einen Tunnel eine Anwendung auf Ihrem Rechner, damit die Prüfung schon zur Verfügung steht, bevor irgendetwas deployt ist.
Das Bauen ist schneller geworden. Das Prüfen muss nachziehen.
Testen in der KI-Webentwicklung braucht eine unabhängige Prüfung gegen das laufende Produkt, denn Tests, die neben der Implementierung entstehen, teilen deren Annahmen. Decken Sie Flows ab, halten Sie den Aufwand im Verhältnis, und lassen Sie die Prüfung beim Pull Request laufen.