Detrás de Escena de una Prueba de Regresión Visual

Bienvenidos. Hablemos sobre las Pruebas de Regresión Visual. Entonces, ¿qué son las Pruebas de Regresión Visual? Son un método para detectar cambios en tu sitio web, aplicación o interfaz de usuario que no fueron intencionados. Piensa en ellas como pruebas unitarias o de integración, pero que se ocupan más de la parte visual de tu aplicación. Hay una descripción más larga para eso, pero eso es un poco aburrido, así que, como estamos hablando de las Pruebas de Regresión Visual, déjame mostrarte. Imagina que estás trabajando en una empresa donde hay un sitio web y tienes un departamento de marketing, y el departamento de marketing quiere introducir un pequeño cambio. El departamento implementa el cambio y luego tomamos una captura de pantalla de esa página. Esto es lo que llamamos una captura actual o una captura de cambio. Esto es después del cambio. Luego, sacamos una versión anterior, cómo se veía el sitio web antes de hacer el cambio. Esto se llama una imagen de referencia. Ahora, si observas ambas versiones antes y después, es posible que puedas detectar las diferencias, pero no es tan fácil porque el ojo humano no es bueno en eso. Entonces, lo que necesitamos es que una máquina nos muestre una máscara de diferencia. Si observas esto, se vuelve realmente obvio qué cambió. Permíteme acercarlo un poco para que puedas ver que en la parte superior agregamos un nuevo enlace de blog. El cambio en el encabezado de marketing también está ahí, y en la parte inferior también hay algunos cambios en el texto de marketing. No es tan obvio para el ojo humano, pero está ahí. Ahora, la prueba de regresión visual detectaría eso y le diría a alguien como el desarrollador, el personal de control de calidad o el gerente de proyectos que, hey, hay un cambio. ¿Qué quieres hacer al respecto? Es posible que estés pensando que, bueno, es solo un pequeño cambio de texto, nada perjudicial. ¿Qué puede salir mal? No es tan importante. En este caso, tal vez tengas razón, pero déjame mostrarte un ejemplo donde no es tan inofensivo. Pero antes de llegar a eso, déjame presentarme rápidamente. Hola, mi nombre es Chris. Soy un ingeniero full-stack. Me encanta el código abierto y soy cofundador de Lost Pixel. Mi pasión por las pruebas de regresión visual es tan grande que comencé a construir un producto con un amigo mío e incluso creamos una empresa en torno a ello. Si quieres ponerte al día conmigo, puedes encontrarme en las redes sociales, en X, Twitter, YouTube, LinkedIn. Solo busca el nombre de usuario Chris Calmer. Sería un gusto conocerte. Muy bien, volvamos al ejemplo del que estaba hablando antes.

Entonces, la imagen está encima de la descripción, lo que dificulta mucho la lectura. Es muy probable que el cliente pierda confianza en tu capacidad para brindar un buen servicio y se frustre, lo que resulta en la pérdida del cliente.

También hay otros casos de uso que me gustaría mostrarte. Por ejemplo, si tienes un sistema de diseño, te gustaría probar todos esos componentes del sistema de diseño. No solo en un estado, sino en varios estados diferentes, como un botón con el mouse encima, haciendo clic, y todas esas cosas. Hay muchas pruebas que puedes hacer. Diseños responsivos. Quieres ver cómo se ve tu sitio web en el escritorio, en una tableta o en un teléfono móvil. Y también el renderizado en navegadores. Quieres asegurarte de que tu sitio web o tu aplicación se vea bien en Firefox, Chrome, Safari e Internet Explorer. Este es un buen caso de uso para pruebas de regresión visual.

O tal vez solo tienes un diseñador que ama los diseños perfectos en píxeles y necesitas asegurarte de que el resultado siga siendo perfecto. Sin importar tu caso de uso, las verificaciones manuales no escalan. Tendrías que verificar cada componente, cada página, cada estado, cada navegador, cada resolución de pantalla en cada cambio de código. Esto no funciona. Necesitas automatizar ese proceso y necesitas usar una herramienta para eso. Afortunadamente, hay muchas herramientas disponibles para pruebas de regresión visual. Algunas son de código abierto. Algunas son soluciones pagas. Hay muchas opciones para elegir.

Como mencioné antes, mi pasión por las pruebas de regresión visual me llevó a crear un producto y construir una empresa en torno a él. Ya sabes, la historia habitual. Ves un problema, intentas resolverlo y terminas con un producto. Pero no te preocupes, hoy no estoy hablando del producto. Solo quiero compartir contigo lo que aprendí mientras construía esta herramienta y lo que realmente sucede detrás de escena en una prueba de regresión visual. Porque desde el exterior, parece una operación simple. Tienes capturas de pantalla que comparas y eso es básicamente todo. Pero hay más que eso. Así que el primer paso es tomar la captura de pantalla. Y esto ya tiene algunos desafíos. Animaciones. Ya sabes, tienes cosas como un spinner de carga, por ejemplo. Esto es algo que realmente dificulta una prueba de regresión visual. Porque cada vez que tomas una captura de pantalla en el proceso de construcción, el spinner puede estar en una posición diferente. Entonces esto es lo que no quieres obtener y, por lo tanto, necesitas detener esas animaciones. Algunas animaciones se basan en JavaScript. Afortunadamente, la mayoría de ellas se basan en CSS, lo cual es muy fácil de detener. Otro ejemplo serían los carruseles y cosas similares. Todos ellos deben detenerse para que no se vean diferentes cada vez que tomas una captura de pantalla.

El siguiente problema con el que tienes que lidiar es la conexión en red. Porque cuando cargas tu página, se realizan solicitudes de red. Y no sabes cuándo terminan, ¿verdad? Entonces podría tomar 200 milisegundos. Podría tomar tres segundos. Pero aún así necesitas tomar una captura de pantalla. Y en este caso, lo mejor es simular tus solicitudes con herramientas como Mock Service Worker. Mantener tus activos locales es algo bueno. Tal vez si no tienes ninguna solicitud de red en absoluto, porque solo estás probando tus componentes, ese es el mejor caso. Eso lo hace fácil. También hay opciones de extender el período de espera para cada prueba. Así que darle cinco segundos más antes de tomar una captura de pantalla.

Esto funciona bien si tienes que tomar unas pocas capturas de pantalla. Pero si tu conjunto de pruebas tiene de 500 a 1,000 capturas de pantalla, esto puede sumar rápidamente mucho tiempo de espera en tu canal de integración continua (CI). No quieres perder ese tiempo. Por lo tanto, tu herramienta de regresión visual debe ser lo suficientemente inteligente para entender que hay más solicitudes entrantes. Y debe esperar y luego tomar las capturas de pantalla.

Otra cosa importante en las pruebas de regresión visual es lidiar con la inestabilidad. Al igual que en una prueba unitaria donde los resultados de la prueba no siempre obtienen una marca verde, a veces obtienen una marca roja sin ninguna razón obvia. Por lo tanto, es necesario combatir la inestabilidad. Una de las cosas que debes hacer es detener las animations. Como mencioné antes, simular tus solicitudes de red es definitivamente algo muy bueno que debes hacer. Además, darle un poco de tiempo de espera, como mencioné antes, ten cuidado con esto. No siempre termina en un buen resultado. Luego, también puedes enmascarar áreas problemáticas. Por ejemplo, si tienes bibliotecas externas que no controlas y son inestables, esto es algo bueno que podrías hacer. Aquí tienes un ejemplo donde puedes ver una página donde, por ejemplo, en la parte superior derecha se muestra un gráfico. Y este gráfico es una tercera biblioteca que siempre renderiza las cosas de manera un poco diferente y no puedes controlarlo. Entonces, la mejor solución es simplemente enmascarar esta área. Y cuando la enmascaras, siempre obtendrás el mismo resultado reproducible, lo que hace que tu prueba sea menos inestable.

Y luego también puedes cuestionar si la prueba todavía tiene sentido. Porque si tienes una inestabilidad muy fuerte, tal vez haya algo mal en tu prueba. Porque no tiene sentido ejecutar una y otra vez la misma prueba y obtener resultados diferentes. Solo te causará más dolores de cabeza y no te dará los resultados que deseas obtener. En general, es una buena idea tratar de descubrir qué causa la inestabilidad. Porque puede haber algo más sucediendo de lo que no eres consciente. Y esto podría convertirse más tarde en un posible error.

Luego, tomar la captura de pantalla en sí. Tienes diferentes opciones. Por ejemplo, si estás tomando capturas de tus páginas completas, generalmente ejecutarás un servidor web. O si es una compilación estática, es aún más simple. Y en el otro caso, donde deseas verificar tus componentes, generalmente usarías algo como Storybook o Ladle.

O una herramienta similar donde solo muestras tus componentes. En diferentes estados. Y sí, apuntas tu herramienta de pruebas de regresión visual en esa dirección. Y se encargará de las capturas de pantalla. También puedes configurar allí qué navegadores quieres utilizar para tomar las capturas de pantalla. Y qué resoluciones manejar. Plantillas, escritorio, móvil, lo que sea.

Hay algo que también me gustaría señalar. Que podría ser útil. Porque puedes hacer algo si ya tienes pruebas de integración, puedes utilizarlas. Para este caso. Porque en lugar de tener que ejecutar el servidor web o generar la compilación estática o ejecutar Storybook. También podrías incluir tu prueba de regresión visual en tu prueba de integración. Básicamente obtendrías dos por el precio de uno. Por ejemplo, en Playwright, si tu prueba de integración está en Playwright. O los pasos de integración se están ejecutando correctamente, al final de tu prueba simplemente podrías crear una captura de pantalla. O en Cypress, diferentes comandos, simplemente creando una captura de pantalla y eso es todo. Ahora esas capturas de pantalla las podrías proporcionar a tu herramienta de pruebas de regresión visual.

También hay algo que puedes hacer con Playwright. Por ejemplo, si no quieres tomar toda la página, sino solo una sección de ella. Puedes usar selectores y seleccionarlos y la captura de pantalla será solo de esos elementos pequeños. Luego, otra cosa con la que necesitamos lidiar son las fuentes. Y las fuentes son problemáticas. Necesito mostrarte un ejemplo para que entiendas mejor. Estas tres capturas de pantalla han sido tomadas con Chrome, Firefox y Safari. Cada uno de ellos tiene un motor de renderizado diferente. Y para el ojo humano, nuevamente, es bastante imposible detectar alguna diferencia. Todo se ve igual para mí. Pero ahora, si uso la máquina para generar imágenes de diferencias, se vuelve obvio. Entonces, aquí en la primera tenemos Chrome versus Firefox.

La segunda es Firefox y Safari, y así sucesivamente. Así que vemos que en la primera ya hay diferencias significativas. Hay menos diferencias en el lado derecho, pero todas están relacionadas con las fuentes. Y esto no solo hace que la fuente se vea diferente, sino que también puede causar cambios en el diseño y otros problemas. Esto es algo que no es realmente bueno. Y hay formas de mitigar estos problemas. Si deseas probar en diferentes navegadores, eso de todas formas es algo bueno.

Entonces, llevarías un seguimiento de tus pruebas de regresión visual para Chrome, Firefox y Safari. Pero si deseas resolverlo solo para un navegador, lo mejor es ejecutarlo en Docker. Porque si tienes un equipo con usuarios de Mac, usuarios de Linux, usuarios de Windows, todos ellos generarán resultados de capturas de pantalla diferentes. Y esto no es comparable. Básicamente, todo el tiempo tendrías una regresión visual con la que no quieres lidiar. Pero la mejor solución de todas sería ejecutar todo en tu canal de integración continua (CI). Porque así obtienes resultados consistentes una y otra vez para todos. No importa de dónde vengan los cambios.

Bien. Ahora que tenemos las capturas de pantalla, encontremos la línea base porque necesitamos compararla con algo. Y este es un tema muy desafiante. Y esto es algo de lo que tu herramienta de pruebas de regresión visual se encargará por ti. Así que imaginemos un gráfico de Git. Porque este es nuestro cambio de código actual en esta edad de confirmación. Y queremos encontrar nuestra línea base para poder compararla. Así que necesitamos retroceder en el tiempo y seguir el gráfico de Git. Saltamos a los puntos verdes, que son los cambios que fueron aprobados en las pruebas de regresión visual. Así que son los que nos interesan. Y podemos obtener nuestra versión de GDBA y tratar de compararla. Pero la verdad es un poco más complicada porque el gráfico de Git nunca se ve tan lineal, ¿verdad? A menos que estés trabajando solo. Pero incluso así, no creo que sea el caso. Por lo general, un gráfico de Git se ve un poco diferente. Tienes ramas, tienes PR, equipos trabajando en ello, se realizan fusiones, se crean bases sin conflictos, y así sucesivamente.

Entonces es un poco más complicado. En este caso, si lo vuelves a mirar, si tenemos nuestro cambio en nuestra rama, debemos seguir a todos los padres para descubrir cuál es nuestra línea base. En este caso, por ejemplo, si sigues así, debes seguir a ambos padres. Porque a veces, si tienes una fusión, no tienes solo un padre en tu confirmación, sino que hay dos o más padres. Para que sea un poco más fácil de entender, veámoslo en forma de tabla aquí. Digamos que solo tenemos cuatro capturas de página que queremos tomar, y esta es la historia en GitHub. No siempre aplicamos cambios a cada página, ¿verdad?

A veces solo hacemos un cambio en una página, a veces aplicamos cambios en varias páginas. Por lo tanto, no puedes tomar simplemente la última compilación que está allí y usarla como tu línea base. Debes reunir todo tu historial de diferentes compilaciones a lo largo del tiempo. Y esto es lo que hace que el proceso sea tan complicado. Por ejemplo, para la página uno, si retrocedemos en el tiempo, el último cambio aprobado fue en esta confirmación. Para la página dos, lo podemos encontrar aquí. Para la página tres, debemos retroceder un poco más en el tiempo porque no se realizó ningún cambio durante algún tiempo. Y esto se vuelve más complicado si tienes una configuración de monorepo con múltiples interfaces. Pero nuevamente, esto es algo de lo que tu herramienta se encargará por ti.

Bien. Ahora que tenemos la línea base para cada una de nuestras capturas, ahora podemos comenzar a compararlas. Como mencioné antes, tenemos la captura actual y la captura base, y podemos crear la imagen de diferencia. Ahora también podemos enmascarar algunas áreas que son inestables. En este caso, quiero eliminar la copia del encabezado y tengo una línea base, por lo que la línea base siempre tendrá el mismo área marcada. Al final, si miras el resultado, la imagen de diferencia ya no marcará estos cambios. Solo marcará los que están fuera de la máscara. Luego debemos pensar en los umbrales. Imaginemos que tenemos una captura de pantalla de una página o una interfaz de usuario que tiene un tamaño de 1200 por 800 píxeles. Esto se traduce en 960,000 píxeles. Si ahora aplicara un umbral no del 1%, sino del 0.1%. Quiero aceptar cambios del 0.1% y no activar la verificación de regresión visual. El 0.1% serían 960 píxeles en esta resolución. Para darte un mejor ejemplo de cómo se ve, sería más o menos un área de 40 por 24 píxeles. No es tan grande, podrías pensar, pero en realidad es bastante para una prueba de regresión visual.

Casi 1000 píxeles de diferencia es mucho. Si aceptaras esto como umbral, significaría que muchos cambios con el tiempo se filtrarían y ni siquiera te darías cuenta. Por lo tanto, debes mantener tus umbrales realmente bajos. Idealmente, comienza con una tolerancia del 0% y luego puedes ajustarla para algunos problemas más pequeños y fluctuantes. La mayoría de las herramientas proporcionan un valor absoluto, por lo que puedes definir, en lugar de porcentajes, que quiero permitir hasta 20 píxeles de cambios, lo cual está bien. A veces encontrarás que los bordes de renderizado, los bordes redondeados, te dan resultados diferentes. El algoritmo de normalización no siempre funciona correctamente, por lo que esos cambios son aceptables. 20 píxeles, nada grave.

Bien. Ahora que tenemos todas esas cosas en su lugar, debemos revisar esos cambios, porque ahora tenemos algunas diferencias. Como ya te mostré antes, puedes usar la máscara de diferencia donde te dirá exactamente dónde están los cambios, pero también hay otra forma de verlo lado a lado, pero esto no es tan bueno porque el ojo humano es realmente malo en eso. Y otra opción es, como puedes ver aquí, puedes usar el control deslizante donde puedes descubrir tú mismo cuáles son las diferencias, así que usa lo que funcione para ti.

Bien. Y al final, debes aprobar o rechazar el cambio. ¿Fue un cambio intencional o es una regresión visual? Tienes que decidirlo. Al final, verás que todas las comprobaciones pasan. Cuando completes esto, cierras el ciclo, el ciclo termina y todo comienza de nuevo. Alguien crea una nueva PR, o tú estás creando una nueva PR, y las líneas base que aprobaste ya forman parte del sistema y se utilizarán la próxima vez en el proceso cuando todo comience de nuevo. Gracias por escuchar. Espero que lo hayas disfrutado. Espero que hayas aprendido algo sobre las pruebas de regresión visual y espero que estés tan emocionado como yo. Encuéntrame en las redes sociales y tal vez nos veamos en React Amsterdam este año. ¡Adiós!