Du hast eine Staging-Kopie deines Shops, ein Testkonto und einen Ordner mit Tests und möchtest wissen, ob Anmeldung, Warenkorb und Checkout nach der heutigen Änderung noch funktionieren. Das ist automatisiertes Web-Testing in seiner kleinsten Form: ein Flow, ein Testbefehl, ein Ergebnis, das du lesen kannst. FlowLatch öffnet den Ordner, führt den Befehl über Shell aus und zeigt den echten Exit-Code auf einer Karte. Wenn der Flow fehlschlägt, zeigt es die Zeile an und schlägt eine Korrektur als Diff vor, und du entscheidest, ob du sie akzeptierst. Die folgenden Schritte benötigen 4 Aktionen vom Ordner bis zum Ergebnis. Arbeite nur an einer App, die du baust oder für die du berechtigt bist, sie zu testen, verwende das Testkonto und Fake-Daten, und nutze für den Zahlungsschritt den Testmodus deines eigenen Payment-Setups, niemals eine echte Karte. E-Mail-Prüfungen gehen an ein für den Test eingerichtetes Postfach.
Starte FlowLatch, wähle den Ordner mit deinen Tests als Arbeitsordner und aktiviere Ask first, damit jede Aktion, die etwas ändert, auf deine Bestätigung wartet. Verbinde ein Modell, falls du das noch nicht getan hast, und nutze die Schaltfläche Test, um den Endpunkt zu prüfen.
Frag nach der Struktur der Tests. list_dir und glob zeigen die Dateien, und read_file öffnet den Checkout-Flow, damit du und der Agent vor dem Ausführen oder Ändern derselben Textgrundlage haben. Jede Aktion erscheint im Chat als Karte mit ihrem Ergebnis.
Teile dem Agenten mit, welchen Testbefehl dein Projekt verwendet. Shell führt ihn unter Windows oder in WSL aus, und die Karte zeigt die vollständige Ausgabe und den echten Exit-Code, keine Zusammenfassung. Erweitere die Karte, wenn du jede Zeile sehen möchtest, und nutze grep in der Ausgabe, um zum fehlgeschlagenen Schritt zu springen.
Frag bei einem Fehler, was die Ausgabe aussagt. Der Agent schlägt eine Bearbeitung als Diff vor, und es wird nichts geschrieben, bis du es akzeptierst. Verwerfe, was falsch aussieht, führe den Befehl dann erneut aus, um den neuen Exit-Code zu sehen. Wiederhole dies, bis der Flow erfolgreich ist oder du weißt, was du an der App ändern musst.
tests/aufgelistettests/checkout-flow-test.txtgeladenyour test commandexit 0FAIL reports/0 Treffer# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textDieser Entwurf ist reiner Text und liegt im Repository neben deinen Tests. Dein eigenes Test-Framework wandelt jeden Schritt in Code um, und FlowLatch nutzt die Datei als Spezifikation, wenn es diesen Code schreibt, ausführt und das Ergebnis mit den drei expect-Zeilen vergleicht. Ändere den Produktnamen und die Seiten, um sie an deine eigene Staging-App anzupassen.
Fang damit an, zu fragen, wo die Tests sind. list_dir zeigt die Ordner, glob listet jede Datei auf, die einem Muster wie den Checkout-Tests entspricht, und read_file öffnet die Dateien, die dich interessieren, damit du siehst, wie ein Flow heute aufgebaut ist. grep sucht dann nach den von ihnen verwendeten Selektoren und Wartezeiten. All dies liest nur, daher ist es ein sinnvoller erster Schritt im Plan only-Modus, der einen Plan erstellt und nichts ausführt. Der Plan überlebt einen Neustart, sodass du morgen weitermachen kannst. Wenn du bereit für echte Ausführungen bist, wechsle zu Ask first und lies den Plan noch einmal durch. Schreibe die Flows auf, die bereits abgedeckt sind, damit du weißt, welche noch einen Test vermissen lassen.
Nach einem Runtime-Upgrade stammen E2E-Suite-Fehler oft aus der Umgebung und nicht von deiner App, also lies den ersten Fehler, bevor du einen Test berührst. Shell führt deinen Testbefehl aus, und die Karte speichert die vollständige Ausgabe und den echten Exit-Code, der der einzige ehrliche Bestanden oder Durchgefallen ist. grep kann den fehlgeschlagenen Schritt aus einem langen Protokoll herausziehen. Frag im Chat nach einer klaren Erklärung des Fehlers, vergleiche sie mit der Ausgabe und entscheide erst dann, ob eine Testdatei bearbeitet werden muss. Wenn der Fehler ein fehlendes Paket oder eine geänderte Einstellung benennt, behebe zuerst die Umgebung und führe denselben Befehl erneut aus. Oft läuft die Suite dann ohne Bearbeitung durch, und der Exit-Code auf der Karte beweist es.
Die Wartung von Selektoren in der UI-Testautomatisierung ist die häufigste Routineaufgabe, da ein geändertes Layout Selektoren, die damit verknüpft waren, kaputt macht. grep findet den alten Selektor in jeder Datei, read_file zeigt die Schritte darum herum an, und edit_file schlägt ein stabiles Label oder eine Test-ID an seiner Stelle vor. In Ask first pausiert der Agent und zeigt den Diff. Akzeptiere die Zeilen, die richtig aussehen, und lass dann Shell den Befehl erneut ausführen. Ein grüner Exit-Code nach der Bearbeitung ist das Ergebnis, das du wolltest, und der Diff bleibt in deinem Repository-Verlauf für den nächsten Reviewer. Wenn der Befehl immer noch fehlschlägt, lies die neue Ausgabe, bevor du nach einer weiteren Änderung fragst, denn eine zweite Bearbeitung auf Basis einer falschen Vermutung macht die Ursache schwerer zu erkennen. Halte jeden Diff klein genug, um ihn in einer Sitzung lesen zu können.
Wenn ein UI-E2E-Test fehlschlägt, ist die wahre Ursache oft eine feste Wartezeit, gemeinsame Testdaten oder die Reihenfolge der Tests, nicht die App. Frag FlowLatch, den fehlerhaften Test mehrmals mit demselben Befehl auszuführen und jeden Exit-Code zu melden. Gemischte Ergebnisse bedeuten, dass der Test flaky ist. Wenn dein Framework einen Screenshot gespeichert hat, liest ocr den Text darin, und der Seitentext aus dem fehlgeschlagenen Lauf liefert einen zweiten Hinweis. Korrigiere die Wartezeit oder die Daten in einem Diff, prüfe ihn und führe den Test erneut aus. Gib jedem Test seine eigenen Daten und setze sie zurück, warte auf eine sichtbare Bedingung statt auf eine feste Pause, und halte Tests unabhängig von der Reihenfolge anderer Tests. Führe den Lauf nach der Korrektur noch einmal durch; ein Durchlauf beweist wenig.
