Máš staging verzi svého e-shopu, testovací účet a složku s testy a chceš vědět, zda přihlášení, přidání do košíku a dokončení objednávky stále fungují po dnešní změně. Toto je automatizované webové testování v jeho nejmenší podobě: jeden tok, jeden příkaz, jeden výsledek, který můžeš přečíst. FlowLatch otevře složku, spustí příkaz přes Shell a zobrazí skutečný exit kód na kartě. Pokud tok selže, ukáže na řádek a navrhne opravu jako diff a ty se rozhodneš, zda ji přijmeš. Následující kroky provedou 4 akce od složky k výsledku. Pracuj pouze na aplikaci, kterou vyvíjíš nebo máš oprávnění testovat, použij testovací účet a fiktivní data a pro platbu použij testovací režim své platební brány, nikdy skutečnou kartu. Kontrolu e-mailů prováděj v testovací schránce určené pro testy.
Spusť FlowLatch, vyber složku s testy jako pracovní složku a zvol možnost Ask first, aby každá akce, která něco změní, čekala na tvé potvrzení. Pokud ještě nemáš připojený model, připoj ho, a použij tlačítko Test pro ověření endpointu.
Ptej se na strukturu testů. Příkazy list_dir a glob zobrazí soubory a read_file otevře proces objednávky, takže ty i agent začnete se stejným textem, než se něco spustí nebo změní. Každá akce se v chatu zobrazí jako karta s výsledkem.
Řekni agentovi, jaký příkaz pro test tvůj projekt používá. Shell ho spustí na Windows nebo ve WSL a karta zobrazí celý výstup a skutečný exit kód, ne jen shrnutí. Rozbal kartu, pokud chceš vidět každý řádek, a použij grep na výstupu pro přeskok na selhající krok.
Při selhání se zeptej, co výstup říká. Agent navrhne úpravu jako diff a nic se nezapisuje, dokud ji nepřijmeš. Zamítni to, co vypadá špatně, a znovu spusť příkaz, abys viděl nový exit kód. Opakuj, dokud tok neprojde, nebo dokud nevíš, co v aplikaci změnit.
tests/vypsánotests/checkout-flow-test.txtnačtenoyour test commandexit 0FAIL reports/0 shod# 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 textTento náčrt je obyčejný text a leží v repozitáři vedle tvých testů. Tvůj vlastní testovací framework přemění každý krok na kód a FlowLatch používá soubor jako specifikaci, když tento kód píše, spouští a porovnává výsledek se třemi řádky expect. Změň název produktu a stránky tak, aby odpovídaly tvé vlastní staging verzi.
Začni tím, že se zeptej, kde jsou testy. list_dir zobrazí složky, glob vylistuje každý soubor, který odpovídá vzoru, jako jsou testy pokladny, a read_file otevře ty, které tě zajímají, abys viděl, jak je tok dnes postaven. grep pak hledá selektory a čekání, která používají. Všechno toto pouze čte, takže je to rozumný první krok v režimu Plan only, který vytvoří plán a nic nespustí. Plán přežije restart, takže se k němu můžeš vrátit zítra. Když budeš připraven na skutečné běhy, přepni na Ask first a ještě jednou si plán přečti. Zapiš si toky, které již jsou pokryty, abys věděl, které postrádají test.
Po aktualizaci runtime často přicházejí selhání sady e2e z prostředí spíše než z tvé aplikace, takže si přečti první chybu, než začneš upravovat test. Shell spustí tvůj příkaz pro test a karta si uchová celý výstup a skutečný exit kód, což je jediný upřímný průchod nebo selhání. grep může vytáhnout selhající krok z dlouhého logu. Požádej v chatu o prosté vysvětlení chyby, porovnej ji s výstupem a až pak se rozhodni, zda je potřeba úprava testovacího souboru. Pokud chyba zmiňuje chybějící balíček nebo změněné nastavení, oprav nejprve prostředí a znovu spusť stejný příkaz. Často sada pak projde bez žádné úpravy a exit kód na kartě to dokazuje.
Údržba selektorů v automatizaci UI testů je nejčastější povinností, protože změněné rozložení rozbije selektory, které byly k němu vázány. grep najde starý selektor ve všech souborech, read_file ukáže kroky kolem něj a edit_file navrhne stabilní label nebo test id na jeho místo. V režimu Ask first agent pozastaví a zobrazí diff. Přijmi řádky, které vypadají správně, a nech Shell znovu spustit příkaz. Zelený exit kód po úpravě je výsledek, který jsi chtěl, a diff zůstane v historii repozitáře pro dalšího reviewera. Pokud příkaz stále selhává, přečti si nový výstup, než požádáš o další změnu, protože druhá úprava nad špatnou domněnkou ztíží vidět příčinu. Udržuj každý diff dostatečně malý, aby se dal přečíst na jedno sezení.
Když UI e2e test selže, skutečnou příčinou často není aplikace, ale pevné čekání, sdílená testovací data nebo pořadí testů. Požádej FlowLatch, aby spustil selhávající test několikrát se stejným příkazem a nahlásil každý exit kód. Smíšené výsledky znamenají, že test je flaky. Pokud tvůj framework uložil snímek obrazovky, ocr přečte text v něm a text stránky z selhávajícího běhu přidá druhou stopu. Oprav čekání nebo data v diffu, zkontroluj ho a znovu spusť test. Poskytni každému testu vlastní data a resetuj je, čekej na viditelný stav místo pevné pauzy a udržuj testy nezávislé na pořadí ostatních. Po opravě běh zopakuj ještě jednou; jeden průchod málo prokazuje.
