Teste de regressão visual

O teste de regressão visual (visual regression testing) verifica como a página se parece, e não o que está no DOM. A primeira execução captura um screenshot de referência (baseline); as execuções seguintes tiram um novo screenshot e o comparam pixel a pixel (ou com um algoritmo perceptual) com essa referência. Qualquer diferença acima de um limite faz o teste falhar e gera uma imagem de diff destacando o que mudou. Ele pega problemas que as assertions funcionais deixam passar, como um botão empurrado para fora da tela por uma mudança de CSS.

Exemplo (Playwright)

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

test('dashboard looks right', async ({ page }) => {
  await page.goto('/dashboard');
  await expect(page).toHaveScreenshot('dashboard.png', {
    fullPage: true,
    mask: [page.getByTestId('last-updated')],
    maxDiffPixels: 100,
  });
});

test('pricing card', async ({ page }) => {
  await page.goto('/pricing');
  await expect(page.getByTestId('pro-plan')).toHaveScreenshot();
});

A primeira execução falha porque ainda não existe baseline e grava uma. Depois de uma mudança de design intencional, gere as baselines de novo com:

npx playwright test --update-snapshots

toHaveScreenshot é uma web-first assertion: ela tira o screenshot de novo até que duas capturas consecutivas sejam iguais, o que evita comparar um quadro no meio de uma animação.

Como deixar estável

• O mesmo ambiente para baselines e execuções. Fontes e anti-aliasing variam entre sistemas operacionais, e é por isso que o Playwright guarda baselines por navegador e plataforma. Gere-as na mesma imagem Docker que o CI usa.
• Mascare o conteúdo dinâmico. Timestamps, avatares, anúncios e gráficos com dados ao vivo sempre vão ser diferentes.
• Congele o tempo e os dados. Use massa de dados fixa e, quando necessário, um relógio mockado.
• Desative as animações. O Playwright desativa as animações CSS nos screenshots por padrão.
• Prefira componentes a páginas inteiras. O screenshot de um único card falha por um motivo; o de uma página inteira falha por vinte.

Erros comuns

• Aprovar diffs sem olhar. Atualizar baselines em massa transforma a suíte em um carimbo de aprovação.
• Tolerância zero em tudo. Diferenças mínimas de renderização geram ruído. Defina um limite pequeno, mas não tão grande que esconda regressões reais.
• Usá-lo no lugar de testes funcionais. Um screenshot pode mostrar que o total está no lugar certo, mas não que é o número certo.