Ai o copie de staging a magazinului tău, un cont de test și un folder cu teste, și vrei să afli dacă autentificarea, adăugarea în coș și checkout funcționează încă după modificarea de azi. Aceasta este testarea web automată în forma ei cea mai simplă: un singur flux, o singură comandă de test, un singur rezultat pe care îl poți citi. FlowLatch deschide folderul, rulează comanda prin Shell și afișează codul de ieșire real pe un card. Dacă fluxul eșuează, indică linia și propune o remediere sub formă de diff, iar tu decizi dacă o accepți. Pașii de mai jos implică 4 acțiuni de la folder la rezultat. Lucrează doar pe o aplicație pe care o construiești sau ai dreptul să o testezi, folosește contul de test și date fictive, și folosește modul de test al configurației tale de plată pentru etapa de plată, niciodată un card real. Verificările de e-mail merg la o căsuță de e-mail de test configurată pentru test.
Pornește FlowLatch, alege folderul care conține teste ca folder de lucru și alege Ask first, astfel încât fiecare acțiune care modifică ceva să aștepte aprobarea ta. Conectează un model dacă nu ai făcut-o încă și folosește butonul Test pentru a verifica endpoint-ul.
Cere structura testelor. list_dir și glob afișează fișierele, iar read_file deschide fluxul de checkout, astfel încât tu și agentul să începeți de la același text înainte de a rula sau modifica orice. Fiecare acțiune apare în chat ca un card cu rezultatul său.
Spune agentului care comandă de test folosește proiectul tău. Shell o rulează pe Windows sau în WSL, iar cardul afișează ieșirea completă și codul de ieșire real, nu un rezumat. Extinde cardul dacă vrei fiecare linie și folosește grep în ieșire pentru a ajunge rapid la pasul care a eșuat.
În caz de eșec, întreabă ce spune ieșirea. Agentul propune o editare sub formă de diff și nimic nu este scris până nu o accepți. Respinge ceea ce pare greșit, apoi rulează din nou comanda pentru a vedea noul cod de ieșire. Repetă până când fluxul trece sau știi ce trebuie modificat în aplicație.
tests/listattests/checkout-flow-test.txtîncărcatyour test commandexit 0FAIL reports/0 potriviri# 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 textAceastă schiță este text simplu și se află în repository lângă teste. Framework-ul tău de testare transformă fiecare pas în cod, iar FlowLatch folosește fișierul ca specificație când scrie acel cod, îl rulează și compară rezultatul cu cele trei linii de așteptare. Modifică numele produsului și paginile pentru a se potrivi cu propria ta aplicație de staging.
Începe prin a întreba unde sunt testele. list_dir arată folderele, glob listează fiecare fișier care se potrivește cu un model, cum ar fi testele de checkout, iar read_file deschide pe cele care te interesează, astfel încât să poți vedea cum este construit un flux astăzi. grep caută apoi selectorii și așteptările pe care le folosesc. Tot acest lucru citește doar, așa că este un prim pas rezonabil în modul Plan only, care scrie un plan și nu rulează nimic. Planul supraviețuiește unei reporniri, așa că te poți întoarce la el mâine. Când ești gata pentru rulări reale, comută la Ask first și citește planul încă o dată. Notează fluxurile care sunt deja acoperite, astfel încât să știi care lipsesc un test.
După o actualizare de runtime, eșecurile suitei e2e provin adesea din mediu, nu din aplicația ta, așa că citește prima eroare înainte să atingi un test. Shell rulează comanda de test, iar cardul păstrează ieșirea completă și codul de ieșire real, care este singurul pass sau fail onest. grep poate extrage pasul care a eșuat dintr-un jurnal lung. Cere o explicație simplă a erorii în chat, compar-o cu ieșirea și abia apoi decide dacă un fișier de test necesită o editare. Dacă eroarea numește un pachet lipsă sau o setare modificată, remediazi mai întâi mediul și rulează din nou aceeași comandă. Adesea, suita trece apoi fără nicio editare, iar codul de ieșire de pe card îl dovedește.
Întreținerea selectorilor în testarea automată a interfeței este cea mai comună sarcină, deoarece un layout modificat strică selectorii legați de acesta. grep găsește vechiul selector în fiecare fișier, read_file arată pașii din jurul lui, iar edit_file propune o etichetă stabilă sau un id de test în locul lui. În Ask first, agentul se oprește și afișează diff-ul. Acceptă liniile care par corecte, apoi lasă Shell să ruleze din nou comanda. Un cod de ieșire verde după editare este rezultatul dorit, iar diff-ul rămâne în istoricul repository-ului tău pentru următorul reviewer. Dacă comanda eșuează încă, citește noua ieșire înainte să ceri o altă modificare, deoarece o a doua editare peste o presupunere greșită face cauza mai greu de văzut. Menține fiecare diff suficient de mic pentru a fi citit într-o ședință.
Când un test e2e ui se strică, cauza reală este adesea o așteptare fixă, date de test partajate sau ordinea testelor, nu aplicația. Cere FlowLatch să ruleze testul care eșuează de mai multe ori cu aceeași comandă și să raporteze fiecare cod de ieșire. Rezultate mixte înseamnă că testul este instabil. Dacă framework-ul tău a salvat o captură de ecran, ocr citește textul din ea, iar textul paginii din rularea eșuată adaugă un al doilea indiciu. Remediază așteptarea sau datele într-un diff, revizuiește-l și rulează din nou testul. Oferă fiecărui test datele sale proprii și resetează-le, așteaptă o condiție vizibilă în loc de o pauză fixă și menține testele independente de ordinea celorlalte. Repetă rularea o dată după remediere; un singur pass dovedește puțin.
