Padrões de Teste E2E

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

Quando Usar Esta Habilidade

• 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 CI/CD
• Testar em vários navegadores
• Validar requisitos de acessibilidade
• Testar designs responsivos
• Estabelecer padrões de teste E2E

Conceitos Principais

1. Fundamentos de Teste E2E

O Que Testar com E2E:

• Jornadas críticas do usuário (login, checkout, cadastro)
• Interações complexas (arrastar e soltar, formulários de várias etapas)
• Compatibilidade entre navegadores
• Integração real de API
• Fluxos de autenticação

O Que NÃO Testar com E2E:

• Lógica em nível de unidade (use testes de unidade)
• Contratos de API (use testes de integração)
• Casos extremos (muito lentos)
• Detalhes de implementação interna

2. Filosofia de Teste

A Pirâmide de Testes:

        /\
       /E2E\         ← Few, focused on critical paths
      /─────\
     /Integr\        ← More, test component interactions
    /────────\
   /Unit Tests\      ← Many, fast, isolated
  /────────────\

Melhores Práticas:

• Teste o comportamento do usuário, não a implementação
• Mantenha os testes independentes
• Torne os testes determinísticos
• Otimize para velocidade
• Use data-testid, não seletores CSS

Padrões Detalhados e Exemplos Práticos

A documentação detalhada dos padrões está em references/details.md. Leia esse arquivo quando o nível de navegação acima for insuficiente.

Melhores Práticas

1. Use Atributos de Dados: data-testid ou data-cy para seletores estáveis
2. Evite Seletores Frágeis: Não confie em classes CSS ou estrutura DOM
3. Teste o Comportamento do Usuário: Clique, digite, veja - não detalhes de implementação
4. Mantenha os Testes Independentes: Cada teste deve ser executado isoladamente
5. Limpe os Dados de Teste: Crie e destrua dados de teste em cada teste
6. Use Page Objects: Encapsule a lógica da página
7. Asserções Significativas: Verifique o comportamento real visível para o usuário
8. Otimize para Velocidade: Use mock quando possível, execução paralela

// ❌ Bad selectors
cy.get(".btn.btn-primary.submit-button").click();
cy.get("div > form > div:nth-child(2) > input").type("text");

// ✅ Good selectors (findBy* commands come from @testing-library/cypress;
// add `import "@testing-library/cypress/add-commands";` to your Cypress support file)
cy.findByRole("button", { name: "Submit" }).click();
cy.findByLabelText("Email address").type("user@example.com");
cy.get('[data-testid="email-input"]').type("user@example.com");

Armadilhas Comuns

• Testes Instáveis: Use esperas adequadas, não timeouts fixos
• Testes Lentos: Use mock de APIs externas, execução paralela
• Excesso de Testes: Não teste todos os casos extremos com E2E
• Testes Acoplados: Testes não devem depender uns dos outros
• Seletores Ruins: Evite classes CSS e nth-child
• Sem Limpeza: Limpe os dados de teste após cada teste
• Testando Implementação: Teste o comportamento do usuário, não os internos

Depurando Testes Falhos

// Playwright debugging
// 1. Run in headed mode
npx playwright test --headed

// 2. Run in debug mode
npx playwright test --debug

// 3. Use trace viewer (record with `use: { trace: 'on-first-retry' }` in the config)
npx playwright show-trace path/to/trace.zip
await page.screenshot({ path: 'screenshot.png' });

// 4. Add test.step for better reporting
test('checkout flow', async ({ page }) => {
    await test.step('Add item to cart', async () => {
        await page.goto('/products');
        await page.getByRole('button', { name: 'Add to Cart' }).click();
    });

    await test.step('Proceed to checkout', async () => {
        await page.goto('/cart');
        await page.getByRole('button', { name: 'Checkout' }).click();
    });
});

// 5. Inspect page state
await page.pause();  // Pauses execution, opens inspector