Teste end-to-end (E2E)

Um teste end-to-end (E2E), ou ponta a ponta, exercita o sistema do jeito que um usuário faz, com todas as camadas reais: navegador, front-end, serviços de back-end, banco de dados, filas e, quando for viável, integrações com terceiros. Ele responde à pergunta que os níveis mais baixos não conseguem: o conjunto todo realmente funciona junto em uma jornada real? Os testes E2E ficam no topo da pirâmide de testes porque dão a confiança mais realista, com o custo mais alto.

Exemplo (Playwright)

import { test, expect } from '@playwright/test';

test('guest can buy a product', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('searchbox', { name: 'Search' }).fill('desk lamp');
  await page.keyboard.press('Enter');
  await page.getByRole('link', { name: 'Desk Lamp' }).click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
  await page.getByLabel('Email').fill('guest@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('heading', { name: 'Thank you for your order' })).toBeVisible();
});

Um único teste passa pelos serviços de busca, catálogo, carrinho, checkout e pedidos. Se o serviço de carrinho serializar os preços errado, este teste pega o problema mesmo quando os testes unitários de todos os serviços passam.

Por que manter poucos

• Lentos. De segundos a minutos cada um, contra milissegundos dos testes unitários.
• Propensos a flakiness. Mais peças móveis significam mais problemas de timing, dados compartilhados e instabilidade de ambiente.
• Diagnóstico ruim. “O checkout falhou” pode ser qualquer um de uma dúzia de serviços.
• Caros de manter. Mudanças na UI se espalham por muitos testes.

Por isso, reserve os testes E2E para as jornadas de negócio críticas, como cadastro, compra e os fluxos principais, e cubra as variações (cada regra de validação, cada tipo de desconto) nos níveis unitário e de API.

Como torná-los confiáveis

• Use espera baseada em condições, como o auto-waiting e as web-first assertions do Playwright ou o WebDriverWait do Selenium, nunca sleeps fixos.
• Crie os dados de teste por APIs no setup em vez de clicar pela UI, e dê a cada teste os seus próprios dados.
• Use locators estáveis: roles, labels e test IDs, em vez de XPath dependente do layout.
• Estruture o código com page objects ou algo parecido, para que uma mudança na UI seja corrigida em um só lugar.

“End-to-end” e “teste de sistema” se sobrepõem: teste de sistema é o nível de teste; E2E descreve o estilo de teste que passa por todas as camadas.