Pruebas de regresión visual

Las pruebas de regresión visual (visual regression testing) comprueban cómo se ve la página en lugar de qué hay en el DOM. La primera ejecución captura una captura de pantalla de referencia (baseline); las ejecuciones posteriores toman una captura nueva y la comparan píxel a píxel (o con un algoritmo perceptivo) con esa referencia. Cualquier diferencia por encima de un umbral hace fallar el test y genera una imagen de diferencias que resalta lo que cambió. Detecta problemas que las aserciones funcionales pasan por alto, como un botón que un cambio de CSS ha empujado fuera de la pantalla.

Ejemplo (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();
});

La primera ejecución falla porque no existe una referencia y la escribe. Tras un cambio de diseño deliberado, regenera las referencias con:

npx playwright test --update-snapshots

toHaveScreenshot es una web-first assertion: vuelve a tomar la captura hasta que dos capturas consecutivas coinciden, lo que evita comparar un fotograma a mitad de una animación.

Cómo hacerlas estables

• El mismo entorno para referencias y ejecuciones. Las fuentes y el antialiasing difieren entre sistemas operativos, por eso Playwright guarda las referencias por navegador y plataforma. Genéralas en la misma imagen de Docker que usa CI.
• Enmascara el contenido dinámico. Las marcas de tiempo, los avatares, los anuncios y los gráficos con datos en vivo siempre serán distintos.
• Congela el tiempo y los datos. Usa datos de prueba fijos y, cuando haga falta, un reloj simulado.
• Desactiva las animaciones. Playwright desactiva por defecto las animaciones CSS en las capturas.
• Prefiere componentes a páginas completas. La captura de una tarjeta falla por un motivo; una página completa, por veinte.

Errores comunes

• Aprobar diferencias sin mirarlas. Actualizar las referencias en bloque convierte la suite en un mero trámite.
• Tolerancia cero en todas partes. Las pequeñas diferencias de renderizado generan ruido. Fija un umbral pequeño, pero no tan grande que oculte regresiones reales.
• Usarlas en lugar de los tests funcionales. Una captura puede mostrar que el total está en el sitio correcto, no que sea la cifra correcta.