Cómo crear un entorno de desarrollo más seguro y eficiente con Playwright Visual Comparisons

Contexto y planteamiento del problema

• Las pruebas de frontend presentan muchas dificultades debido a los cambios en la UI y a entradas de usuario impredecibles.
• Las pruebas verificadas manualmente tienen limitaciones, por lo que se consideró introducir pruebas automatizadas.
• Las pruebas E2E existentes basadas en grabación (TestProject, Playwright) tienen un alto costo de mantenimiento y son vulnerables a los cambios en la UI.

Introducción de Playwright Visual Comparisons

• Se aplicó un enfoque de pruebas de regresión visual para detectar cambios en la UI.
• Se guarda una captura de pantalla de referencia y, después de cambios en el código, se compara para detectar modificaciones.
• Es posible comparar imágenes con los métodos 2-up, Swipe, Highlight y Onion Skin.

Principales problemas encontrados durante la implementación y sus soluciones

1. Falsos fallos provocados por diferencias mínimas (0.01%)
   Problema: se producen diferencias en el renderizado de fuentes según el entorno de ejecución de las pruebas (SO, navegador, configuración de pantalla, etc.).
   Solución: usar contenedores Docker para ejecutar todas las pruebas en el mismo entorno.

2. Necesidad de tomar la captura después de que termine la carga de datos
   Problema: si se toma la captura antes de que la página termine de cargar por completo, puede incluir la UI de carga.
   Solución: usar una función utilitaria con getByText + toBeVisible para esperar hasta que aparezca una cadena específica.

3. Diferencias en las capturas causadas por elementos animados
   Problema: los elementos de CSS animation, Canvas, SVG y WebGL se capturan en momentos distintos cada vez, lo que vuelve las pruebas flaky.
   Solución: aplicar distintos mecanismos para desactivar animaciones y optimizar adicionalmente la eficiencia de ejecución de las pruebas.

4. Detección innecesaria de cambios por plugins de terceros (iframe, etc.)
   Problema: plugins de terceros como feedback de clientes, encuestas y chatbots se cargan mediante iframe y generan cambios visuales.
   Solución: al generar capturas, aplicar CSS común para ocultar iframe y elementos de plugins específicos.

5. Fallo al verificar elementos inferiores en páginas con scroll
   Problema: toHaveScreenshot captura por defecto solo la parte visible de la pantalla, por lo que se requiere manejo relacionado con el scroll.
   Solución: aplicar la opción fullPage: true para capturar una captura de toda la página.

Conclusión

• Las pruebas de regresión visual permiten automatizar eficazmente la detección de cambios en la UI.
• Aunque no es una solución perfecta, mejora tanto la productividad de desarrollo como la estabilidad de las pruebas.
• Se necesitan mejoras continuas y optimización del entorno de pruebas.