vibe coding - Playwright - testing - construir con IA
4 min lectura

Tu agente cambió el CSS: detecta una regresión visual antes de lanzar

Compara capturas móviles con Playwright después de cambios hechos por IA. Código copiable, revisión del diff y reglas para no ocultar fallos.

Tu agente cambió el CSS: detecta una regresión visual antes de lanzar

Le pides a un agente de código que cambie el texto del botón de tu landing. El diff parece pequeño, pero en móvil el botón salta a dos líneas y tapa el precio. La app compila y el test funcional pasa; aun así, la pantalla que ve tu cliente está rota. Para ese tipo de cambio existe una prueba distinta de la accesibilidad y de la lógica: comparar capturas del mismo estado antes y después.

La documentación oficial de Playwright ofrece toHaveScreenshot(). En la primera ejecución guarda una imagen base; en las siguientes compara una captura nueva con esa referencia. Es útil para quien construye con Cursor, Claude Code, v0 o cualquier asistente que puede tocar CSS sin que el cambio visual quede claro en el código. No es una opinión sobre el diseño: es una alarma para revisar diferencias.

Empieza por una pantalla y un estado estable

Elige la página que afecta una decisión de usuario, por ejemplo la landing con su llamado a la acción, y fija un viewport móvil. Prepara contenido estable: si cada carga muestra una imagen aleatoria, un reloj o un precio dinámico, tendrás ruido. Playwright advierte que el renderizado varía entre sistema operativo, versión de navegador, fuentes y hardware; genera y compara la referencia en un entorno consistente.

Si tu proyecto aún no usa Playwright Test, instala la dependencia y el navegador:

npm install --save-dev @playwright/test
npx playwright install chromium

Arranca la app localmente y cambia la URL del ejemplo por la tuya. Guarda como tests/landing-visual.spec.js:

const { test, expect } = require('@playwright/test');

test('landing móvil conserva su composición', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('http://localhost:3000/');
  await expect(page.getByRole('main')).toBeVisible();
  await expect(page).toHaveScreenshot('landing-mobile.png');
});

Con la app abierta, ejecuta npx playwright test tests/landing-visual.spec.js. La primera vez se crea la imagen base; revisa que sea la pantalla correcta y súbela al control de versiones junto con el test. Vuelve a ejecutar sin cambios: debería coincidir. Después modifica deliberadamente el ancho del botón o un margen y comprueba que la prueba señale la diferencia. Esa segunda ejecución te confirma que el control detecta algo real en tu proyecto.

Comparación de captura base aprobada, nueva captura y diferencia en el botón de una interfaz móvil
La comparación solo tiene sentido si navegador, tamaño y datos de la pantalla son equivalentes.

Qué hacer cuando falle

Abre el informe de Playwright y mira tres imágenes: la base esperada, la captura actual y la diferencia. La interfaz de pruebas permite inspeccionarlas con un deslizador. Decide si el cambio era intencional. Si lo era, revisa la nueva pantalla con criterio de producto y actualiza la referencia con npx playwright test --update-snapshots. No aceptes automáticamente toda captura nueva: eso convertiría la prueba en un trámite.

Si el cambio no era intencional, entrega al agente el diff visual y una instrucción precisa: “En viewport 390×844, el botón de la landing se parte y tapa el precio. Corrige solo ese diseño, conserva la acción del botón y muéstrame la nueva captura y el diff de código.” Después ejecuta también el test funcional y una prueba manual en móvil. Una captura igual puede ocultar una interacción rota.

Reduce el ruido sin esconder fallos

Según Playwright, las animaciones están desactivadas por defecto durante la comparación. Si una zona cambia por datos volátiles, puedes fijar esos datos en el entorno de prueba o aplicar una hoja de estilo temporal con stylePath. Ajustar threshold o maxDiffPixels también es posible, pero hazlo solo después de entender la diferencia: un umbral amplio puede dejar pasar un botón desplazado. El objetivo no es tener tests verdes, sino detectar una regresión que afecta al usuario.

Este tutorial no ejecutó la prueba sobre tu repositorio; el ejemplo sigue la API documentada por Playwright y necesita que adaptes URL, selector y entorno. La decisión práctica es empezar con una sola pantalla crítica, probar que el test falla ante un cambio deliberado y revisar cada nueva referencia como si fuera un cambio de producto. Así el agente puede editar rápido sin que la revisión visual dependa solo de tu memoria.

Fuentes: Playwright, Visual comparisons; Playwright, UI Mode. Consultadas el 2 de noviembre de 2026.

Recibe lo nuevo en tu correo

Workshops gratis, herramientas y novedades de IA aplicadas a negocio, sin humo.

🎓 Workshops en vivo🛠️ Herramientas nuevas⚡ Novedades de IA

Sin spam. Te das de baja cuando quieras.

Comentarios

Aún no hay comentarios. Sé el primero.

Deja un comentario