Pruebas de regresión visual en móviles: Playwright gratis

Las pruebas de regresión visual comparan capturas de tus páginas con imágenes de referencia aprobadas y fallan cuando cambian los píxeles. En diseños móviles detectan lo que las pruebas funcionales no ven: un botón de menú empujado fuera de una pantalla de 360px, un título que ocupa tres líneas, una cuadrícula de tarjetas que se colapsa mal en el ancho de tableta. Puedes ejecutarlas gratis con toHaveScreenshot() de Playwright en viewports de móvil y de tableta, y después decidir si merece la pena un servicio de pago para los flujos de revisión y el renderizado multinavegador en la nube.

Cómo funcionan las pruebas de regresión visual

Una prueba visual tiene cuatro pasos: capturar una referencia, capturar de nuevo tras un cambio, comparar las dos imágenes y dejar que una persona acepte o rechace la diferencia. Los cambios aceptados pasan a ser la nueva referencia.

La comparación es donde se diferencian las herramientas. La comparación de píxeles (Playwright, BackstopJS) cuenta los píxeles cambiados y falla por encima de un umbral que tú fijas. Applitools compara con su propia IA visual en lugar de un recuento estricto de píxeles, y Percy y Chromatic son servicios alojados con un panel de revisión. Todas necesitan páginas estables: si un reloj, un anuncio o una animación cambia entre dos ejecuciones, la prueba falla sin motivo real. La mayor parte del trabajo de configuración de abajo consiste en eliminar ese ruido.

Herramientas comparadas

El aserto integrado de Playwright cubre el caso gratuito y autoalojado. A octubre de 2026:

Percy cuenta cada página en cada navegador y ancho como una captura, así que dos páginas en tres anchos de móvil y tableta y en dos navegadores ya suman doce. Los precios y los límites de los planes proceden de la página de precios de cada proveedor el 25 de octubre de 2026, y cambian a menudo.

Configura pruebas visuales en viewports móviles

Esta configuración usa @playwright/test 1.64 (la versión vigente a 25 de octubre de 2026). Necesita Node.js y un sitio al que la máquina de pruebas pueda acceder, en local o desplegado.

1. Instala Playwright y sus navegadores:

   npm init playwright@latest

2. Añade proyectos móviles en playwright.config.ts. Cada descriptor de dispositivo define el viewport, la relación de píxeles, el user agent y el soporte táctil, y elige el motor (iPhone 15 se ejecuta en WebKit, Pixel 7 en Chromium).

   import { defineConfig, devices } from '@playwright/test';
   
   export default defineConfig({
     testDir: './visual',
     use: { baseURL: 'http://localhost:4321' },
     expect: {
       toHaveScreenshot: { maxDiffPixelRatio: 0.01 },
     },
     projects: [
       { name: 'pixel-7', use: { ...devices['Pixel 7'] } },
       { name: 'iphone-15', use: { ...devices['iPhone 15'] } },
       { name: 'tablet', use: { browserName: 'chromium', viewport: { width: 820, height: 1180 } } },
     ],
   });

   En Playwright 1.64, el descriptor Pixel 7 tiene un viewport de 412 × 839 con una relación de píxeles de 2,625, y iPhone 15 tiene 393 × 659 con 3. El maxDiffPixelRatio del 1% es un valor de partida que tú ajustas, no un estándar.

3. Escribe la prueba. Limítala a las páginas cuyo diseño más importa:

   // visual/pages.spec.ts
   import { test, expect } from '@playwright/test';
   
   const pages = ['/', '/pricing', '/blog'];
   
   for (const path of pages) {
     test(`layout ${path}`, async ({ page }) => {
       await page.goto(path);
       await page.evaluate(async () => { await document.fonts.ready; });
       await expect(page).toHaveScreenshot({
         fullPage: true,
         mask: [page.locator('[data-testid="live-date"]')],
       });
     });
   }

4. Crea las referencias y confírmalas en el repositorio:

   npx playwright test --update-snapshots

   Playwright guarda un PNG por prueba y proyecto, con el nombre del proyecto y la plataforma al final del nombre del archivo (por ejemplo ...-iphone-15-linux.png). Confirma las carpetas *-snapshots.

5. Ejecuta npx playwright test en cada pull request. Una comparación fallida hace fallar la prueba; abre el informe HTML con npx playwright show-report para ver el fallo. Si el cambio es intencionado, actualiza las referencias con --update-snapshots y confírmalas junto con el cambio de código.

Los valores por defecto ayudan: toHaveScreenshot() espera hasta que dos capturas consecutivas coinciden antes de comparar, desactiva las animaciones y transiciones CSS y oculta el cursor de texto (documentación de la API de Playwright). Su opción scale tiene por defecto "css", un píxel de imagen por píxel CSS, así que una referencia de iPhone mide 393 px de ancho en lugar de 1179 y las comparaciones son rápidas.

Revisa el diseño antes de crear las referencias

Una referencia registra cómo se veía la página cuando la capturaste. Si la primera captura ya tiene un diseño móvil roto, cada ejecución posterior defenderá ese error. Antes de crear las referencias, mira cada página en los anchos que pruebas:

1. Abre la página en un ancho de móvil. Mobile View Extension recarga la pestaña con el user agent, el tamaño de pantalla y la relación de píxeles de un teléfono, y puede mostrar dos dispositivos lado a lado, así que puedes revisar juntos los diseños de teléfono y tableta de una misma URL. Funciona en localhost.
2. Desplázate por toda la página y revisa la navegación, los títulos que ocupan varias líneas, las tablas y los elementos fijos.
3. Corrige lo que encuentres y ejecuta --update-snapshots.

La extensión renderiza con el motor de Chrome de escritorio y con ratón, así que muestra el diseño, no el renderizado de Safari ni el comportamiento táctil. El proyecto WebKit de Playwright cubre parte de esa diferencia, y un iPhone real cubre el resto. Una rutina más amplia para revisiones manuales está en cómo probar el diseño responsive, y las capturas puntuales para tickets, en hacer una captura de pantalla móvil de un sitio web.

Corrige las diferencias de capturas inestables

Las diferencias inestables provienen de cosas que cambian entre ejecuciones, así que la solución es que esas cosas sean siempre iguales. Estas son las causas habituales y qué hacer con cada una:

La primera fila explica los fallos que parecen aleatorios. La documentación de Playwright advierte de que el renderizado puede variar según el sistema operativo del equipo, la versión, los ajustes y el hardware, y la plataforma forma parte del nombre de la captura por esa razón: una referencia creada en un Mac (-darwin.png) no se usa en un runner Linux de CI (-linux.png). Elige un solo entorno para las referencias. Ejecutar npx playwright test --update-snapshots dentro de la misma imagen Docker que usa el CI elimina esa fuente de diferencias.

Un archivo stylePath es el lugar más limpio para ocultar el ruido en todas las pruebas:

/* visual/screenshot.css */
iframe, [data-testid="cookie-banner"] { visibility: hidden; }

import path from 'node:path';

await expect(page).toHaveScreenshot({
  stylePath: path.join(__dirname, 'screenshot.css'),
});

La misma opción puede ir en expect.toHaveScreenshot de la configuración para aplicarse a todas las pruebas.

Lo que las pruebas visuales no detectan

Una comparación de capturas revisa los píxeles en los motores que ejecutas. No comprueba que un botón funcione, que un objetivo táctil sea lo bastante grande, ni cómo se comporta la página en el navegador real de un teléfono, con su barra de herramientas y su teclado. El WebKit de Playwright se parece mucho a Safari, pero no es Safari en un iPhone. Mantén las pruebas funcionales junto a las visuales, y cubre los navegadores reales con la lista de comprobación de pruebas multinavegador.

Mantén la suite pequeña. Cada página, proyecto y estado multiplica el número de imágenes que hay que revisar. De tres a diez plantillas clave (inicio, un listado, una página de detalle, un formulario) en dos tamaños de móvil y uno de tableta mantienen la revisión en unas pocas docenas de imágenes por ejecución. Esa cifra es un punto de partida que ajustar (una decisión de diseño), no una regla.

Preguntas frecuentes

¿Son gratuitas las pruebas de regresión visual?

Sí, con herramientas de código abierto. El toHaveScreenshot() de Playwright y BackstopJS se ejecutan en local y en tu CI sin coste. Servicios de pago como Percy, Chromatic y Applitools añaden renderizado alojado y paneles de revisión, y Percy y Chromatic tienen planes gratuitos de 5.000 capturas o instantáneas al mes a octubre de 2026.

¿Cuál es la diferencia entre pruebas visuales y pruebas de capturas de pantalla?

Las dos hacen una captura y la comparan con una referencia aprobada. La diferencia está en la comparación: Playwright y BackstopJS cuentan los píxeles cambiados, mientras que Applitools usa IA visual (consulta la tabla de herramientas de arriba).

¿Por qué fallan mis capturas de Playwright en CI pero pasan en local?

Porque las referencias se hicieron en otro sistema operativo o con otra versión del navegador. Playwright incluye la plataforma en el nombre del archivo de captura, y las fuentes y el antialiasing son distintos en macOS y en Linux. Crea las referencias en la misma imagen Docker que usa el CI.

¿Cómo ignoro el contenido dinámico en las pruebas visuales?

Usa la opción mask para cubrir elementos como fechas y anuncios, u oúltalos con una hoja de estilos stylePath. Para regiones completas que cambian, toma la captura de un elemento estable en lugar de la página completa.