Je hebt een staging-kopie van je shop, een testaccount en een map met tests, en je wilt weten of inloggen, toevoegen aan winkelwagen en afrekenen nog steeds werken na de wijziging van vandaag. Dit is geautomatiseerd webtesten in de kleinste vorm: één flow, één testcommando, één resultaat dat je kunt lezen. FlowLatch opent de map, voert het commando uit via Shell en toont de echte exitcode op een kaart. Als de flow faalt, wijst het naar de regel en stelt het een fix voor als diff, en jij beslist of je deze accepteert. De onderstaande stappen vereisen 4 acties van map naar resultaat. Werk alleen aan een app die je bouwt of waar je gemachtigd bent om te testen, gebruik het testaccount en nepgegevens, en gebruik de testmodus van je eigen betaalopstelling voor de betaalstap, nooit een echte kaart. E-mailcontroles gaan naar een testinbox die voor de test is ingesteld.
Start FlowLatch, kies de map met je tests als werkmap en kies Ask first, zodat elke actie die iets wijzigt wacht op je goedkeuring. Verbind een model als je dat nog niet hebt gedaan, en gebruik de knop Test om het eindpunt te controleren.
Vraag naar de structuur van de tests. list_dir en glob tonen de bestanden, en read_file opent de checkout-flow, zodat jij en de agent beginnen vanuit dezelfde tekst voordat er iets wordt uitgevoerd of gewijzigd. Elke actie verschijnt in de chat als een kaart met het resultaat.
Geef de agent door welk testcommando je project gebruikt. Shell voert het uit op Windows of in WSL, en de kaart toont de volledige uitvoer en de echte exitcode, geen samenvatting. Vouw de kaart uit als je elke regel wilt zien, en gebruik grep in de uitvoer om naar de mislukte stap te springen.
Bij een fout, vraag wat de uitvoer zegt. De agent stelt een bewerking voor als diff, en er wordt niets geschreven totdat je het accepteert. Wijs af wat fout lijkt, voer het commando daarna opnieuw uit om de nieuwe exitcode te zien. Herhaal dit totdat de flow slaagt of je weet wat je in de app moet wijzigen.
tests/lijsttests/checkout-flow-test.txtgeladenyour 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 textDeze outline is platte tekst en staat in de repository naast je tests. Jouw eigen testframework zet elke stap om in code, en FlowLatch gebruikt het bestand als specificatie wanneer het die code schrijft, uitvoert en het resultaat vergelijkt met de drie expect-regels. Pas de productnaam en de pagina's aan zodat ze overeenkomen met je eigen staging-app.
Begin met te vragen waar de tests zich bevinden. list_dir toont de mappen, glob lijst elk bestand op dat overeenkomt met een patroon zoals de checkout-tests, en read_file opent de bestanden die je interesseert, zodat je kunt zien hoe een flow er vandaag uitziet. grep zoekt vervolgens naar de selectors en de waits die ze gebruiken. Dit leest allemaal alleen, dus het is een verstandige eerste stap in Plan only-modus, die een plan opstelt en niets uitvoert. Het plan overleeft een herstart, dus je kunt er morgen weer naar terugkeren. Als je klaar bent voor echte runs, schakel je over op Ask first en lees het plan nog een keer. Schrijf de flows op die al gedekt zijn, zodat je weet welke nog een test missen.
Na een runtime-upgrade komen e2e-suite-fouten vaak voort uit de omgeving in plaats van uit je app, dus lees de eerste fout voordat je een test aanraakt. Shell voert je testcommando uit en de kaart bewaart de volledige uitvoer en de echte exitcode, wat de enige eerlijke pass of fail is. grep kan de mislukte stap uit een lange log halen. Vraag om een eenvoudige uitleg van de fout in de chat, vergelijk deze met de uitvoer en beslis pas daarna of een testbestand een bewerking nodig heeft. Als de fout verwijst naar een ontbrekend pakket of een gewijzigde instelling, los dan eerst de omgeving op en voer hetzelfde commando opnieuw uit. Vaak slaagt de suite dan zonder enige bewerking, en de exitcode op de kaart bewijst dit.
Selectoronderhoud in ui-testautomatisering is de meest voorkomende klus, omdat een gewijzigde lay-out selectors die eraan gekoppeld waren, kapotmaakt. grep vindt de oude selector in elk bestand, read_file toont de stappen eromheen en edit_file stelt een stabiel label of test-id voor als vervanging. In Ask first pauzeert de agent en toont de diff. Accepteer de regels die er goed uitzien, laat Shell daarna het commando opnieuw uitvoeren. Een groene exitcode na de bewerking is het resultaat dat je wilde, en de diff blijft in je repositorygeschiedenis voor de volgende reviewer. Als het commando nog steeds faalt, lees dan de nieuwe uitvoer voordat je om een andere wijziging vraagt, omdat een tweede bewerking bovenop een verkeerde gok de oorzaak moeilijker zichtbaar maakt. Houd elke diff klein genoeg om in één keer te kunnen lezen.
Wanneer een ui-e2e-test faalt, is de echte oorzaak vaak een vaste wait, gedeelde testgegevens of de volgorde van de tests, niet de app. Vraag FlowLatch om de mislukte test meerdere keren uit te voeren met hetzelfde commando en rapporteer elke exitcode. Gemengde resultaten betekenen dat de test flaky is. Als je framework een screenshot heeft opgeslagen, leest ocr de tekst erin, en de paginatext van de mislukte run voegt een tweede aanwijzing toe. Los de wait of de gegevens op in een diff, bekijk het en voer de test opnieuw uit. Geef elke test zijn eigen gegevens en reset deze, wacht op een zichtbare conditie in plaats van een vaste pauze, en houd tests onafhankelijk van de volgorde van andere tests. Voer de run een keer opnieuw uit na de fix; één keer slagen bewijst weinig.
