Automação de UI para os sites e apps que você cria

O que o agente pode fazer pelos seus testes

• Arquivosread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep e glob funcionam dentro da pasta de trabalho do chat, e um contador mostra arquivos criados, editados e lidos.
• Shellexecuta seu comando de teste, um linter ou uma compilação no Windows local, WSL ou via SSH em um servidor que você possui, e julga o sucesso pelo código de saída real. Comandos perigosos são bloqueados.
• Webweb_search encontra páginas e http_get lê uma página de documentação oficial, para que uma dúvida sobre seletor ou espera possa ser verificada contra o manual do próprio framework.
• Capturas de tela e imagensocr lê o texto em uma captura de tela salva, por exemplo o banner de erro de uma execução falha, e gen_image salva arquivos de imagem reais quando você precisa de um.
• Orquestraçãotask divide verificações independentes entre sub-agentes paralelos, run_on_model envia uma etapa difícil para um modelo maior, e skill armazena um playbook reutilizável como sua rotina de reparo habitual.
• Modos de aprovaçãoAuto-run age imediatamente, Ask first pausa antes de ações que alteram algo e mostra o diff, e Plan only escreve um plano e não executa nada. Planos sobrevivem a reinicializações.
• Cronexecuta um prompt em um agendamento, por exemplo para rodar seu comando de teste nos horários definidos e reportar o código de saída no chat, para que um fluxo que quebrou durante a noite seja a primeira coisa que você vê.
• Modelosconecte um provedor de IA na nuvem através de um endpoint de API padrão, um modelo rodando localmente no seu PC ou o modelo embutido que está pronto para uso sem seu próprio endpoint. O botão Test verifica um endpoint antes de você começar.

Quatro tarefas que o agente executa em um projeto de teste

Escrever o primeiro fluxo

As melhores práticas para testes e2e começam com uma lista curta de fluxos que nunca devem falhar, então peça ao FlowLatch para escrever apenas esses. list_dir e glob mostram como seus testes existentes estão nomeados, read_file abre um como modelo, e write_file cria o novo arquivo para o fluxo de login com uma conta de teste e dados fictícios. Shell então executa seu comando de teste, e o card mostra o código de saída real. Um primeiro raramente é o definitivo, então peça uma mudança por vez, como um nome mais claro ou uma verificação adicionada no texto da página. Antes de aceitar, leia o novo arquivo no diff, execute-o você mesmo uma vez e mantenha-o apenas se corresponder ao fluxo que você pretendia.

Executar a suíte e ler a falha

Shell executa seu comando de teste e o card mantém o resultado completo, para que um resultado vermelho nunca seja um palpite. grep pesquisa esse resultado pela etapa falha, e se seu framework salvou uma captura de tela, ocr lê a mensagem nela. Para reduzir a instabilidade em testes end to end, peça ao FlowLatch para executar o teste falho novamente com o mesmo comando e comparar os códigos de saída. Uma aprovação seguida de falha aponta para uma espera fixa, dados de teste compartilhados ou a ordem dos testes. Peça uma explicação curta no chat, depois revise-a contra o resultado antes de alterar qualquer arquivo.

Reparar um seletor após mudança de layout

Se vale a pena testar e2e para trabalho frontend depende do fluxo, então cubra login e checkout primeiro. Quando o layout da página muda, grep encontra todos os seletores que estavam vinculados a ele, read_file mostra as etapas ao redor e edit_file propõe rótulos estáveis ou test ids em vez disso. Em Ask first, FlowLatch pausa antes de cada edição e mostra um diff, um arquivo por vez. Aceite as linhas que parecem corretas, rejeite o resto, então deixe Shell executar a suíte novamente para ver o novo código de saída. Mantenha o diff pequeno para que um revisor possa lê-lo em um minuto.

Mover uma suíte para outro framework

Ao migrar testes e2e entre frameworks, mantenha ambas as suítes no repositório até que a nova passe. FlowLatch lista os testes antigos com glob, lê cada um com read_file e escreve o novo arquivo correspondente com write_file, um fluxo por vez. web_search e http_get podem ler a própria documentação do novo framework para a sintaxe que você não lembra. Execute ambas as suítes com Shell, compare os códigos de saída e aprove cada arquivo em Ask first antes que o antigo seja removido. Planos sobrevivem a reinicializações, então uma migração longa pode continuar no dia seguinte.