UI-Automatisierung für die Websites und Apps, die Sie selbst entwickeln

Was der Agent für Ihre Tests leisten kann

• Dateienread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep und glob arbeiten im Arbeitsordner des Chats, und ein Zähler zeigt erstellte, gelesene und geänderte Dateien an.
• Shellführt Ihren Testbefehl, einen Linter oder einen Build lokal unter Windows, WSL oder per SSH auf einem Server, den Sie besitzen, aus, und bewertet den Erfolg am echten Exit-Code. Gefährliche Befehle sind blockiert.
• Webweb_search findet Seiten, und http_get liest eine offizielle Dokumentationsseite, sodass eine Frage zu einem Selektor oder einer Wartezeit gegen das eigene Handbuch des Frameworks geprüft werden kann.
• Screenshots und Bilderocr liest den Text in einem gespeicherten Screenshot, zum Beispiel den Fehlerbanner eines fehlgeschlagenen Durchlaufs, und gen_image speichert echte Bilddateien, wenn Sie eine benötigen.
• Orchestrierungtask teilt unabhängige Checks auf parallele Sub-Agents auf, run_on_model sendet einen komplexen Schritt an ein größeres Modell, und skill speichert ein wiederverwendbares Skript, wie Ihre übliche Reparaturroutine.
• GenehmigungsmodiAuto-run führt sofort aus, Ask first pausiert vor Aktionen, die etwas ändern, und zeigt den Diff, und Plan only erstellt einen Plan und führt nichts aus. Pläne überleben Neustarts.
• Cronführt einen Prompt nach Zeitplan aus, zum Beispiel, um Ihren Testbefehl zu den von Ihnen festgelegten Zeiten auszuführen und den Exit-Code im Chat zu melden, sodass ein Flow, der über Nacht kaputtging, das Erste ist, was Sie lesen.
• Modelleverbinden Sie einen Cloud-KI-Anbieter über einen Standard-API-Endpunkt, ein lokal auf Ihrem PC laufendes Modell oder das integrierte Modell, das ohne Ihren eigenen Endpunkt bereit ist. Die Test-Schaltfläche prüft einen Endpunkt, bevor Sie starten.

Vier Aufgaben, die der Agent in einem Testprojekt erledigt

Ersten Flow schreiben

Best Practices für E2E-Tests beginnen mit einer kurzen Liste von Flows, die niemals brechen dürfen, also bitten Sie FlowLatch, nur diese zu schreiben. list_dir und glob zeigen, wie Ihre bestehenden Tests benannt sind, read_file öffnet einen als Muster, und write_file erstellt die neue Datei für den Anmelde-Flow mit einem Testkonto und Fake-Daten. Shell führt dann Ihren Testbefehl aus, und die Karte zeigt den echten Exit-Code. Ein erster Entwurf ist selten endgültig, also bitten Sie um eine Änderung nach der anderen, wie einen klareren Namen oder eine zusätzliche Prüfung des Seitentextes. Lesen Sie die neue Datei im Diff, bevor Sie sie akzeptieren, führen Sie sie einmal selbst aus und behalten Sie sie nur, wenn sie zum gemeinten Flow passt.

Suite ausführen und Fehler lesen

Shell führt Ihren Testbefehl aus, und die Karte speichert die vollständige Ausgabe, sodass ein rotes Ergebnis nie eine Vermutung ist. grep durchsucht diese Ausgabe nach dem fehlgeschlagenen Schritt, und wenn Ihr Framework einen Screenshot gespeichert hat, liest ocr die Nachricht darin. Um Flakiness in End-to-End-Tests zu reduzieren, bitten Sie FlowLatch, den fehlgeschlagenen Test erneut mit demselben Befehl auszuführen und die Exit-Codes zu vergleichen. Ein Pass gefolgt von einem Fail deutet auf einen festen Wait, gemeinsame Testdaten oder die Reihenfolge der Tests hin. Bitten Sie um eine kurze Erklärung im Chat, prüfen Sie sie dann gegen die Ausgabe, bevor Sie eine Datei ändern.

Selektor nach einer Layoutänderung reparieren

Ob E2E-Testing sich für Frontend-Arbeit lohnt, hängt vom Flow ab, also decken Sie zuerst Anmeldung und Checkout ab. Wenn sich das Seitendesign ändert, findet grep jeden Selektor, der damit verknüpft war, read_file zeigt die umgebenden Schritte, und edit_file schlägt stabile Labels oder Test-IDs vor. In Ask first pausiert FlowLatch vor jeder Bearbeitung und zeigt einen Diff, eine Datei nach der anderen. Akzeptieren Sie die Zeilen, die richtig aussehen, lehnen Sie den Rest ab, und lassen Sie dann Shell die Suite erneut ausführen, um den neuen Exit-Code zu sehen. Halten Sie den Diff klein, damit ein Reviewer ihn in einer Minute lesen kann.

Suite in ein anderes Framework verschieben

Bei der Migration von E2E-Tests zwischen Frameworks behalten Sie beide Suiten im Repository, bis die neue besteht. FlowLatch listet die alten Tests mit glob auf, liest jede mit read_file und schreibt die passende neue Datei mit write_file, einen Flow nach dem anderen. web_search und http_get können die eigene Dokumentation des neuen Frameworks für Syntax lesen, an die Sie sich nicht erinnern. Führen Sie beide Suiten mit Shell aus, vergleichen Sie die Exit-Codes, und genehmigen Sie jede Datei in Ask first, bevor die alte entfernt wird. Pläne überleben Neustarts, sodass eine lange Migration am nächsten Tag fortgesetzt werden kann.