Padrões de Teste E2E

Crie suítes de teste de ponta a ponta (end-to-end) confiáveis, rápidas e fáceis de manter que proporcionem confiança para enviar código rapidamente e detectar regressões antes dos usuários.

Use esta habilidade quando

• Implementar automação de testes de ponta a ponta
• Depurar testes instáveis ou não confiáveis
• Testar fluxos de trabalho críticos do usuário
• Configurar pipelines de teste em CI/CD
• Testar em vários navegadores
• Validar requisitos de acessibilidade
• Testar designs responsivos
• Estabelecer padrões de teste E2E

Não use esta habilidade quando

• Você só precisa de testes unitários ou de integração
• O ambiente não pode suportar automação de UI estável
• Você não pode provisionar contas ou dados de teste seguros

Instruções

1. Identifique jornadas críticas do usuário e critérios de sucesso.
2. Crie seletores estáveis e estratégias de dados de teste.
3. Implemente testes isolados com asserções observáveis e rastreamento; diagnostique novas tentativas em vez de contar uma nova tentativa como uma passagem comum.
4. Execute em CI com paralelização e captura de artefatos.

Segurança

• Evite executar testes destrutivos em produção.
• Use dados de teste dedicados e limpe saídas sensíveis.

Recursos

• resources/implementation-playbook.md para padrões e modelos detalhados de E2E.

Exemplo prático

Entrada: login inválido às vezes parece bem-sucedido porque o teste lê o erro antes que a renderização termine. Use uma conta de fixture dedicada e afirme await expect(page.getByRole('alert')).toContainText('Invalid credentials'). Execute o teste sem novas tentativas e confirme que o painel permanece inacessível. Esperado: o estado de falha é observado de forma confiável; um erro atrasado não pode passar silenciosamente.

Entradas e pré-requisitos

Uma URL de teste autorizada, contas/dados isolados, o runner de navegador instalado e estados conhecidos de sucesso/falha. O playbook usa rotas e adaptadores específicos do projeto; instale apenas as dependências que sua suíte existente precisa.

Limitações

• Um backend ou provedor de pagamento simulado prova apenas o limite simulado; mantenha verificações de integração reais separadas.
• Verificações automatizadas de acessibilidade perdem problemas de interação e de tecnologia assistiva.
• Novas tentativas, timeouts maiores e snapshots atualizados podem ocultar regressões; preserve evidências de falha inicial.
• Ferramentas de navegador não podem validar um ambiente interativo bloqueado ou indisponível. Relate essa lacuna e continue com testes independentes.