Warum eine Web App Testing MCP-Verbindung mehr bringt als das Lesen des Codes
Ein statischer Blick in eine Webanwendung zeigt Ihnen, was der Code beabsichtigt. Er zeigt nicht, was der Browser daraus macht. In der Lücke dazwischen steckt der Großteil der für Nutzer sichtbaren Fehler, und diese Lücke wird größer, je mehr Code von einem Agenten stammt, der die App nie gerendert gesehen hat.
Was auffällt, was ein Review übersieht
State, der überdauert
Ein Modal hinterlässt eine Scroll-Sperre, ein Filter bleibt in einem Kontext bestehen, in dem er keinen Sinn ergibt.
Erst bei der zweiten Interaktion sichtbar, nie im Diff.
Rendern vor den Daten
Die Seite wird gezeichnet, der Fetch löst auf, und nichts rendert neu.
Beim Benutzen der App zuverlässig reproduzierbar, sonst praktisch unsichtbar.
Das zweite Konto
Annahmen über Besitzverhältnisse und Sichtbarkeit, die in der Session des Entwicklers gelten und in keiner anderen.
Lokale Entwicklung
Arbeit an Web-Apps passiert auf localhost, lange bevor irgendetwas deployt wird, und eine Prüfung, die nur eine öffentliche URL erreicht, kommt zu spät, um noch zu beeinflussen, was Sie bauen. Lokale Ziele werden unterstützt, die Prüfung steht also schon während der Arbeit zur Verfügung und nicht erst nach einem Deploy. Wie das aktuell funktioniert, steht in der Dokumentation.
Die Einrichtung
Der MCP-Server ist ein eigenes Paket, getrennt vom CLI, veröffentlicht als @testsprite/testsprite-mcp. Sie tragen ihn mit einem API-Key aus dem Dashboard in die MCP-Einstellungen Ihres Editors ein, und der Editor startet ihn als Subprozess. Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot und Trae unterstützen ihn alle; die genaue Konfiguration unterscheidet sich je nach Client und steht in der Dokumentation zur MCP-Installation.
Was zuerst abgedeckt werden sollte
Registrieren, abmelden, anmelden. Der häufigste Totalausfall in einer generierten Web-App.
Etwas anlegen und neu laden. Trennt „die Anzeige hat sich aktualisiert“ von „der Datensatz existiert“.
Der Hauptablauf mit einem zweiten Konto. Findet die Berechtigungsannahmen, die in der eigenen Session des Entwicklers stecken.
Die Drei-Zustände-Falle
Web-Apps sind insofern ungewöhnlich, als dieselbe Funktion gleichzeitig in drei widersprüchlichen Zuständen sein kann, und die meisten Laufzeitfehler sind ein Widerspruch zwischen ihnen.
Der Server hat einen Datensatz. Der Browser hat eine Kopie im Speicher. Und der Nutzer hat ein mentales Modell aus dem, was er einen Moment zuvor gesehen hat. Ein Löschvorgang, der den Datensatz und die Kopie im Speicher entfernt, die Zeile auf dem Bildschirm aber stehen lässt, hinterlässt einen Nutzer, der sicher ist, dass das Löschen fehlgeschlagen ist. Ein Speichervorgang, der die Anzeige aktualisiert, aber nicht den Server, erzeugt das Gegenteil.
Praktisch bedeutet das: Eine Prüfung, die nur einen der drei Zustände betrachtet, beweist sehr wenig. Eine Assertion direkt nach einer Aktion prüft die Kopie im Browser. Eine Assertion nach einem Neuladen prüft den Server. Die Aktion zweimal auszuführen prüft, ob die erste etwas hinterlassen hat. Diese drei zusammen decken das meiste ab, was tatsächlich bei den Nutzern ankommt, und für keine davon muss man den Code lesen.
Dann muss es die Session überdauern
Eine MCP-Verbindung deckt den Moment der Änderung ab. Für Regressionen müssen dieselben Prüfungen laufen, ob nun jemand an der Tastatur sitzt oder nicht.
Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Er lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt, sodass sich in Ihrem Repository nichts ändert.
GitHub Actions setzt den Schritt in Ihren eigenen Workflow, konfiguriert über das Terminal. Die aktuellen Befehle finden Sie im CLI-Repository.
Was TestSprite prüft und ein Diff nicht kann
Es öffnet die laufende Anwendung und benutzt sie, und nur so lassen sich die drei genannten Fehler sehen. State, der nach einer Interaktion zurückbleibt, ein Rendering, das seine Daten nie einholt, und Verhalten, das sich für ein zweites Konto unterscheidet: Im Quellcode ist all das unsichtbar, im Gebrauch offensichtlich.
Weil die Verbindung innerhalb der Agent-Schleife sitzt, findet die Prüfung als Teil der Änderung statt und nicht danach. Der Agent erstellt den Fall, führt ihn aus, liest die Abweichung und iteriert, und Sie sehen das Ergebnis statt des Hin und Her.
Am Ende steht eine Reihe von Abläufen, die bei jeder Änderung erneut verifiziert werden, sodass die Berechtigungsannahme oder der veraltete Filter nicht klammheimlich zurückkehren kann, sobald die Session vorbei ist, in der sie gefunden wurden.
Braucht es meinen Quellcode?
Nein. Es bedient die laufende Anwendung über deren Oberfläche und meldet das Verhalten zurück. Ihr Agent hat den Code ohnehin schon.
Kann es einen lokalen Dev-Server testen?
Ja, für Frontend-Läufe, über einen Tunnel von Ihrem Rechner aus. Rein lokale Backend-Ziele brauchen weiterhin eine erreichbare URL.
Was ist mit Abläufen, die echte E-Mails oder echte Zahlungen brauchen?
Nutzen Sie Testmodi und dedizierte Konten. Alles, was einen echten Seiteneffekt bei Dritten auslöst, prüfen Sie besser bewusst manuell.
Wie viele Prüfungen sollte eine Web-App haben?
Beginnen Sie mit den drei oben genannten und ergänzen Sie für jeden Bug, der Ihnen tatsächlich begegnet, eine weitere. Abdeckung, die sich an realen Fehlern orientiert, schlägt Abdeckung, die auf eine Prozentzahl zielt.
Ist das dasselbe wie das CLI?
Dieselbe Funktionalität, ein anderer Einstiegspunkt. MCP passt zur Arbeit im Editor, das CLI zu Skripten und Pipelines.
Öffnen Sie die App, lesen Sie sie nicht nur.
Eine Web App Testing MCP-Verbindung lässt den Agenten zurückgebliebenen State, Rendern-vor-Daten- und Zweitkonto-Probleme finden, die kein Diff zeigt. Decken Sie zuerst Anmeldung, Persistenz und ein zweites Konto ab und lassen Sie die Prüfungen danach auch nach dem Ende der Session weiterlaufen.