Hai una copia di staging del tuo negozio, un account di test e una cartella di test, e vuoi sapere se l'accesso, l'aggiunta al carrello e il checkout funzionano ancora dopo la modifica di oggi. Questo è il test web automatizzato nella sua forma più semplice: un flusso, un comando di test, un risultato leggibile. FlowLatch apre la cartella, esegue il comando tramite Shell e mostra il codice di uscita reale su una scheda. Se il flusso fallisce, indica la riga e propone una correzione come diff, e tu decidi se accettarla. I passaggi seguenti richiedono 4 azioni dalla cartella al risultato. Lavora solo su un'app che costruisci o sei autorizzato a testare, usa l'account di test e dati fittizi, e usa la modalità test della tua configurazione di pagamento per il passaggio di pagamento, mai una carta reale. I controlli email vanno a una casella di posta di test configurata per il test.
Avvia FlowLatch, scegli la cartella che contiene i tuoi test come cartella di lavoro e scegli Ask first, così ogni azione che modifica qualcosa attende il tuo OK. Connetti un modello se non l'hai ancora fatto, e usa il pulsante Test per verificare l'endpoint.
Chiedi la struttura dei test. list_dir e glob mostrano i file, mentre read_file apre il flusso di checkout così tu e l'agente partite dallo stesso testo prima che venga eseguita qualsiasi modifica. Ogni azione appare nella chat come una scheda con il relativo risultato.
Indica all'agente quale comando di test usa il tuo progetto. Shell lo esegue su Windows o in WSL, e la scheda mostra l'output completo e il codice di uscita reale, non un riassunto. Espandi la scheda se vuoi ogni riga, e usa grep sull'output per saltare al passaggio fallito.
In caso di errore, chiedi cosa dice l'output. L'agente propone una modifica come diff, e nulla viene scritto finché non lo accetti. Rifiuta ciò che sembra sbagliato, poi esegui di nuovo il comando per vedere il nuovo codice di uscita. Ripeti finché il flusso non passa o sai cosa modificare nell'app.
tests/listedtests/checkout-flow-test.txtloadedyour test commandexit 0FAIL reports/0 matches# 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 textQuesta bozza è testo semplice e vive nel repository accanto ai tuoi test. Il tuo framework di test trasforma ogni passaggio in codice, e FlowLatch usa il file come specifica quando scrive quel codice, lo esegue e confronta il risultato con le tre righe di attesa. Cambia il nome del prodotto e le pagine per adattarli alla tua app di staging.
Inizia chiedendo dove si trovano i test. list_dir mostra le cartelle, glob elenca ogni file che corrisponde a un modello come i test di checkout, e read_file apre quelli che ti interessano così puoi vedere come è costruito un flusso oggi. grep cerca poi i selettori e le attese che usano. Tutto questo legge solo, quindi è un primo passo sensato in modalità Plan only, che scrive un piano ed esegue nulla. Il piano sopravvive a un riavvio, quindi puoi tornarci domani. Quando sei pronto per esecuzioni reali, passa a Ask first e leggi di nuovo il piano. Annota i flussi già coperti, così sai quali mancano di un test.
Dopo un aggiornamento del runtime, i fallimenti della suite e2e derivano spesso dall'ambiente piuttosto che dalla tua app, quindi leggi il primo errore prima di toccare un test. Shell esegue il tuo comando di test e la scheda mantiene l'output completo e il codice di uscita reale, che è l'unico passaggio o fallimento onesto. grep può estrarre il passaggio fallito da un lungo log. Chiedi una spiegazione semplice dell'errore nella chat, confrontalo con l'output, e solo allora decidi se un file di test necessita una modifica. Se l'errore nomina un pacchetto mancante o un'impostazione cambiata, correggi prima l'ambiente ed esegui di nuovo lo stesso comando. Spesso la suite passa senza nessuna modifica, e il codice di uscita sulla scheda lo dimostra.
La manutenzione dei selettori nell'automazione dei test UI è la mansione più comune, perché un layout cambiato rompe i selettori che vi erano legati. grep trova il vecchio selettore in ogni file, read_file mostra i passaggi intorno ad esso e edit_file propone un'etichetta stabile o un test id al suo posto. In Ask first l'agente si ferma e mostra il diff. Accetta le righe che sembrano giuste, poi lascia che Shell esegua di nuovo il comando. Un codice di uscita verde dopo la modifica è il risultato che volevi, e il diff rimane nella cronologia del repository per il prossimo revisore. Se il comando fallisce ancora, leggi il nuovo output prima di chiedere un'altra modifica, perché una seconda modifica sopra un'ipotesi sbagliata rende più difficile vedere la causa. Mantieni ogni diff piccolo abbastanza da leggere in una sola seduta.
Quando un test UI e2e si rompe, la causa reale è spesso un'attesa fissa, dati di test condivisi o l'ordine dei test, non l'app. Chiedi a FlowLatch di eseguire il test fallito più volte con lo stesso comando e di riportare ogni codice di uscita. Risultati misti significano che il test è fragile. Se il tuo framework ha salvato uno screenshot, ocr legge il testo al suo interno, e il testo della pagina dall'esecuzione fallita aggiunge un secondo indizio. Correggi l'attesa o i dati in un diff, rivedilo, ed esegui di nuovo il test. Dai a ogni test i suoi dati e resettali, aspetta una condizione visibile invece di una pausa fissa, e mantieni i test indipendenti dall'ordine degli altri. Ripeti l'esecuzione una volta dopo la correzione; un passaggio dimostra poco.
