Pruebas de regresión visual para detectar cambios de interfaz

Comprueban cosas distintas y complementarias. Una prueba funcional verifica el comportamiento: que al hacer clic en un botón ocurra lo que debe ocurrir, que un formulario se envíe, que una cuenta dé el resultado correcto. No dice nada sobre cómo se ve la pantalla. Una prueba de regresión visual verifica justamente eso: el aspecto. Compara cómo se ve la interfaz ahora con cómo se veía antes y avisa si algo cambió. El caso donde se nota la diferencia es un ajuste de estilo que descoloca un elemento sin romper su función: todas las pruebas funcionales pasan porque el botón sigue funcionando, pero el diseño se rompió, y solo la prueba visual lo detecta. Un proyecto completo usa ambas.

Es la imagen de referencia con la que se comparan las capturas futuras: la foto de cómo se ve una pantalla cuando está correcta. La primera vez que corre la prueba no existe con qué comparar, así que la herramienta toma una captura y la guarda como línea base, versionada junto al código. A partir de ahí, cada ejecución toma una captura nueva de la misma pantalla y la compara contra esa línea base. Si coinciden dentro de la tolerancia, la prueba pasa; si difieren, falla y muestra las diferencias. Cuando un cambio visual es intencional, la línea base queda desactualizada y hay que regenerarla para que la nueva imagen pase a ser la referencia, siempre después de que una persona confirme que el cambio es el que se buscaba.

Casi siempre por falsos positivos, que son el desafío central de la regresión visual. Las causas más comunes son las diferencias de renderizado de fuentes entre distintos sistemas operativos, que hacen que el mismo texto se dibuje con variaciones mínimas; los datos que cambian en cada ejecución, como una fecha, un nombre de usuario o un contador; las animaciones o el contenido dinámico capturados a mitad de movimiento; y las diferencias mínimas en los bordes por el suavizado. La solución no es aflojar la tolerancia hasta que deje de fallar, porque eso también dejaría pasar cambios reales, sino controlar el entorno para que sea siempre el mismo, fijar los datos con valores estables, congelar las animaciones antes de capturar, y ajustar el umbral solo lo justo para el suavizado.

Regenerando la línea base para que la nueva imagen pase a ser la referencia, pero solo después de verificar que el cambio es correcto. El flujo es: la prueba falla porque la interfaz cambió, mirás la imagen de diferencias que genera la herramienta, confirmás que ese cambio es el que buscabas y no un accidente, y recién entonces ejecutás el comando que actualiza las capturas de referencia. La nueva línea base se revisa y se versiona junto con el cambio de código que la motivó, para que quede claro por qué cambió. Lo que hay que evitar es actualizar a ciegas cada vez que algo falla, porque si aprobás cualquier diferencia sin mirarla, la prueba deja de servir para lo único que importa: atrapar el cambio que no querías.

Para empezar, Playwright alcanza y sobra: trae la comparación visual incorporada con una sola aserción que gestiona las líneas base, la comparación píxel a píxel y la generación de imágenes de diferencias, sin necesidad de instalar nada más. Es el camino recomendado si ya usás Playwright para tus pruebas. Existen además servicios y herramientas dedicados a la regresión visual que agregan capacidades como comparación en la nube contra muchos navegadores y dispositivos, flujos de aprobación en equipo y detección más inteligente de cambios, que tienen sentido en proyectos grandes con equipos de diseño. Pero para la enorme mayoría de los casos, y desde luego para aprender, la funcionalidad nativa de Playwright cubre por completo lo que hace falta.

Porque el aspecto exacto de una pantalla depende del entorno donde se renderiza: el sistema operativo, la versión del navegador y las fuentes instaladas influyen en cómo se dibujan el texto y los elementos. Si generás la línea base en tu computadora y la comparación corre en un entorno distinto, con otras fuentes u otro navegador, las dos capturas van a diferir por esas razones ajenas al código, y la prueba fallará con falsos positivos masivos que no señalan ningún problema real. Por eso las pruebas visuales se generan y comparan siempre en el mismo entorno, que en la práctica suele ser un contenedor idéntico tanto en tu máquina como en el pipeline, y muchas veces las líneas base que valen son las que produce el propio pipeline, no las de cada persona.