Você tem uma cópia de staging da sua loja, uma conta de teste e uma pasta de testes, e quer saber se login, carrinho e checkout ainda funcionam após a mudança de hoje. Este é o teste web automatizado na sua forma mais simples: um fluxo, um comando de teste, um resultado legível. O FlowLatch abre a pasta, executa o comando via Shell e mostra o código de saída real em um cartão. Se o fluxo falhar, ele aponta a linha e propõe uma correção como diff, e você decide se aceita. Os passos abaixo resumem 4 ações da pasta ao resultado. Trabalhe apenas em um app que você constrói ou tem autorização para testar, use a conta de teste e dados fictícios, e use o modo de teste da sua configuração de pagamento para o passo de pagamento, nunca um cartão real. As verificações de e-mail vão para uma caixa de entrada de teste configurada para o teste.
Inicie o FlowLatch, defina como pasta de trabalho a pasta que contém seus testes e selecione Ask first para que toda ação que altere algo aguarde sua confirmação. Conecte um modelo se ainda não o fez, e use o botão Test para verificar o endpoint.
Pergunte pela estrutura dos testes. list_dir e glob mostram os arquivos, e read_file abre o fluxo de checkout para que você e o agente comecem a partir do mesmo texto antes que qualquer ação seja executada ou alterada. Cada ação aparece no chat como um cartão com seu resultado.
Informe ao agente qual comando de teste seu projeto usa. O Shell o executa no Windows ou no WSL, e o cartão mostra a saída completa e o código de saída real, não um resumo. Expanda o cartão se quiser ver cada linha, e use grep na saída para ir direto à etapa falha.
Em caso de falha, pergunte o que a saída indica. O agente propõe uma edição como diff, e nada é gravado até que você aceite. Rejeite o que parecer errado, depois execute o comando novamente para ver o novo código de saída. Repita até que o fluxo passe ou você saiba o que alterar no app.
tests/listadotests/checkout-flow-test.txtcarregadoyour test commandexit 0FAIL reports/0 correspondências# 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 textEste esboço é texto puro e vive no repositório junto aos seus testes. Seu próprio framework de teste converte cada etapa em código, e o FlowLatch usa o arquivo como especificação quando gera esse código, o executa e compara o resultado com as três linhas de expectativa. Altere o nome do produto e as páginas para corresponder ao seu app de staging.
Comece perguntando onde estão os testes. list_dir mostra as pastas, glob lista todos os arquivos que correspondem a um padrão, como os testes de checkout, e read_file abre os que interessam para você ver como um fluxo é construído hoje. grep então busca os seletores e os waits que eles usam. Tudo isso apenas lê, então é um primeiro passo sensível no modo Plan only, que cria um plano e não executa nada. O plano sobrevive a uma reinicialização, então você pode voltar a ele amanhã. Quando estiver pronto para execuções reais, mude para Ask first e leia o plano mais uma vez. Anote os fluxos que já estão cobertos, para saber quais ainda faltam um teste.
Após uma atualização de runtime, falhas na suíte e2e muitas vezes vêm do ambiente, e não do seu app, então leia o primeiro erro antes de tocar em um teste. Shell executa seu comando de teste e o cartão mantém a saída completa e o código de saída real, que é a única passagem ou falha honesta. grep pode extrair a etapa falha de um log longo. Peça uma explicação simples do erro no chat, compare com a saída e só então decida se um arquivo de teste precisa de edição. Se o erro cita um pacote faltante ou uma configuração alterada, corrija o ambiente primeiro e execute o mesmo comando novamente. Muitas vezes a suíte passa sem nenhuma edição, e o código de saída no cartão prova isso.
A manutenção de seletores em automação de testes de interface é a tarefa mais comum, porque um layout alterado quebra seletores vinculados a ele. grep encontra o seletor antigo em todos os arquivos, read_file mostra as etapas ao redor dele e edit_file propõe um rótulo estável ou um test id no lugar. No Ask first, o agente pausa e mostra o diff. Aceite as linhas que parecerem corretas, depois deixe o Shell executar o comando novamente. Um código de saída verde após a edição é o resultado que você queria, e o diff permanece no histórico do seu repositório para o próximo revisor. Se o comando ainda falhar, leia a nova saída antes de pedir outra alteração, porque uma segunda edição sobre um palpite errado torna a causa mais difícil de ver. Mantenha cada diff pequeno o suficiente para ser lido em uma única sessão.
Quando um teste e2e de interface quebra, a causa real muitas vezes é um wait fixo, dados de teste compartilhados ou a ordem dos testes, e não o app. Peça ao FlowLatch para executar o teste falho várias vezes com o mesmo comando e relatar cada código de saída. Resultados mistos significam que o teste é instável. Se seu framework salvou uma captura de tela, ocr lê o texto nela, e o texto da página da execução falha adiciona uma segunda pista. Corrija o wait ou os dados em um diff, revise-o e execute o teste novamente. Dê a cada teste seus próprios dados e redefina-os, aguarde uma condição visível em vez de uma pausa fixa, e mantenha os testes independentes da ordem uns dos outros. Repita a execução mais uma vez após a correção; uma passagem prova pouco.
