Anthropic / webapp-testing
Como impedir que um agente afirme que a mudança funciona?
Tornando a conferência parte do trabalho, e não um passo opcional.
O que vale lembrar
- A falha que ela evita é o relatório falso e confiante, que é a mais cara.
- Precisa de aplicação rodando. Não é análise estática.
- Peça observações, não conclusões. O que apareceu na tela é verificável; funcionou não é.
- Combina com verification-before-completion, que transforma o hábito em regra.
01O que muda na prática
A falha padrão de agentes de código não é escrever código ruim. É escrever código plausível e depois relatar que a tarefa está pronta sem nunca ter rodado. Cada hora perdida assim é gasta descobrindo a falha mais tarde, em lugar pior.
Operar a aplicação transforma o relatório em evidência. O que serve não são as palavras do agente, e sim a sequência de ações e o que a página fez em resposta.
02Onde decepciona
Ela verifica comportamento, não intenção. Um fluxo pode passar em todos os passos e ainda ser o fluxo errado, o que é uma pergunta de produto.
Seletores frágeis e problemas de tempo vêm junto da automação de navegador de sempre, então faça checagens específicas em vez de amplas.
Instalação e primeira execução
- Instale a partir de anthropics/skills, sob Apache 2.0.
- Deixe a aplicação rodando antes, porque a skill opera um app real e não imaginado.
- Peça que a checagem seja descrita como ação de usuário e observação esperada, não como afirmação de sucesso.
Perguntas que as pessoas realmente fazem
- Substitui a suíte de testes?
- Não. Ela verifica o trabalho em andamento. Testes duradouros continuam no repositório.
- A aplicação precisa estar rodando?
- Sim. Ela opera uma aplicação real, então o servidor precisa estar de pé.
- O que devo pedir no relatório?
- Ações e observações: o que foi clicado e o que apareceu depois. Conclusão sem observação é justamente a falha que ela evita.
Fontes
Versões legíveis por máquina desta página