Vamos a lo Visual: Pruebas Visuales en tu Proyecto Vue.JS

Hola y bienvenidos a mi sesión aquí en Vue.js Live. Estoy muy contenta de tenerlos aquí y de que parezca que están interesados en aprender más sobre las pruebas visuales a través de aplicaciones, porque siendo honesta con ustedes, me ha salvado en varias ocasiones, y espero poder brindarles la misma experiencia, especialmente porque las pruebas pueden ser a veces un poco intimidantes.

Pero bueno, antes de eso, mi nombre es Ramona Schwering. Trabajo como ingeniera de software en Chopware, que es una empresa que ofrece una plataforma de comercio electrónico de código abierto. Y hay mucho VU involucrado, así que llevo trabajando con VU desde hace tres días, creo. Además de eso, me convertí en una experta desarrolladora de Google en tecnologías web y embajadora de Cypress. Y sí, supongo que no les sorprenderá escuchar que soy especialmente conocida por las pruebas, y espero poder hacer que las pruebas sean accesibles para todos, y especialmente sin dolor, o un poco menos dolorosas, tal vez, para todos.

Y sin más preámbulos, hay un punto en las pruebas que me gustaría mostrarles. Y no sé si son similares a mí, pero a veces cuando estoy usando mi teléfono móvil, con aplicaciones, ya sea VU o no, hay algunos errores que encuentro a menudo, pero no estoy segura si es porque soy perfeccionista o si ustedes lo sienten así. Pero hay errores que no son bloqueadores de lanzamiento. Son pequeños errores de interfaz de usuario o errores tipográficos. Simplemente se ven feos, ¿verdad? Así que creo que básicamente están en todas partes. Y dejan una cierta impresión si no los corriges.

Miren este, que tomé hace algún tiempo de mi teléfono móvil, donde esta cadena en el medio de ella, keine Mitteilungen, o en inglés no notification. Está claramente roto, ¿verdad? Y lo puedes encontrar básicamente en todas partes. También es el caso de grandes empresas como Google, donde tienes un botón en el lugar equivocado, ¿verdad? O echa un vistazo a esta aplicación de Facebook, donde el botón tiene un relleno completamente incorrecto. Hay tantos ejemplos que podría mostrarles, pero tenemos un cierto marco de tiempo. A veces, para ser honesta, me siento un poco afectada por esto, y no es solo mi perfeccionismo, creo. Porque me pregunto una cosa. ¿Confiarían en esas aplicaciones, si tienen una aplicación o un sitio web con muchos errores de interfaz de usuario, que simplemente se ven rotos o no muestran ningún signo de cuidado? ¿Confiarían en esas aplicaciones, por ejemplo, con los datos de su tarjeta de crédito? Bueno, no estoy muy segura cuando se trata de mi opinión. Pero no quiero ser demasiado estricta aquí tampoco, porque todos somos humanos, ¿verdad? Detrás de todas las aplicaciones, detrás de todos los sitios web, hay un desarrollador. Y nosotros, los humanos, a veces hacemos cosas un poco extrañas. Y hay un fenómeno, que es, al menos en mi opinión, una de las razones por las que se producen este tipo de errores. Es un fenómeno que se llama ceguera inatencional. Es bien conocido en psicología, y se representa no solo en clases de psicología o en la psicología en general, sino también en anuncios de tráfico como el famoso whodunit del Reino Unido. Pueden echar un vistazo a este video más tarde. Lo publiqué aquí como un código QR. Todos esos videos, todas esas campañas se centran en el hecho de que una persona no nota un estímulo inesperado en la viñeta, simplemente debido a la falta de atención y no debido a ningún defecto visual o ceguera o déficit visual. Imaginen a un diseñador que construye un banner maravilloso pero no se da cuenta de que hay un enorme error tipográfico en el titular. Cosas así.

Supongo que todos han tenido una situación así, ¿verdad? Pero, ¿no tenemos pruebas para este tipo de situaciones? Tenemos una buena automatización de pruebas, ¿verdad? Tenemos pruebas de unidad, pruebas de integración, pruebas end-to-end. ¿No es así? ¿No deberían detectarlo? Y lo hacen. Pero hay un problema, al menos en mi opinión. Así que diría que no siempre lo detectan, porque todos esos tipos de pruebas solo probarán lo que se supone que deben probar. Me gusta decir que las pruebas end-to-end no miran a izquierda ni derecha. Por lo tanto, las cosas podrían pasar desapercibidas si están fuera del concepto, fuera de las cosas que no se han escrito explícitamente, ¿verdad? Entonces, ¿cómo podemos resolver esta situación o al menos mejorarla un poco? Bueno, podríamos decirlo de esta manera.

Necesitamos darle ojos a nuestras pruebas. ¿Cómo lo hacemos automáticamente como humanos, verdad? Como vemos las cosas, no siempre nos enfocamos en una sola cosa. Por eso queremos hacer pruebas visuales. ¿Qué significa exactamente esto? ¿Qué es la prueba visual y cómo funciona? Bueno, no sé si vieron mi video promocional en Twitter, pero hice un pequeño corte en él y fue totalmente intencional. Así que imaginen mi video o esos dos fotogramas del video como un rompecabezas de encontrar las diferencias y me encantaría hacerlos en mi título. Me encantó encontrar todas las diferencias en él. ¿Pueden encontrar las diferencias en este rompecabezas y en este pequeño video aquí? Supongo que la más obvia ya fue encontrada. Las gafas. Cambié mis gafas a lo largo del video. Otra diferencia es el pingüino aquí, antes era un elefante. Y la caja aquí tenía un color diferente. Al principio era blanca. Y mientras editaba mis diapositivas, vi una cuarta diferencia incluso. El logo de GitHub en mi brazo había desaparecido. En fin, así fue. Pero sí, cuatro diferencias que nosotros como humanos podemos encontrar muy rápidamente, ¿verdad? Quiero que una prueba haga exactamente lo mismo. Quiero que la prueba encuentre esas diferencias como lo haría un humano. Y puede lograrlo mediante una comparación de capturas de pantalla. Así que tomas una captura de pantalla de tu rama principal o de cualquier otra cosa que consideres como el estado actual, que es la forma correcta en que debería verse tu aplicación. Define lo que es correcto. Y luego haces una nueva captura de pantalla actual de tu rama, de tu nueva función, lo que sea que estés construyendo en este momento, siempre y cuando sea tomada de tu aplicación Vue, y luego comparas esas capturas de pantalla y resaltas las diferencias. Como un rompecabezas de encontrar las diferencias básicamente. Cuando tenemos esas diferencias, podemos decidir si el cambio es intencional o no. ¿Fue una característica que construimos o algún cambio que hicimos en la interfaz de usuario que es visible y que hicimos a propósito, o es un error visual? La prueba no puede decidir esto completamente por sí misma todavía. ¿Cómo podría hacerlo? Así que hay algunas herramientas que te brindan algo de IA, algo de aprendizaje automático, pero en mi opinión todavía necesitamos una revisión realizada por un ser humano real que pueda decir si esto es intencional o no. Entonces, hay algunas herramientas que podrías considerar para implementar estas pruebas visuales. Tal vez herramientas de Apple, que ofrecen algo de IA, Percy o Chromatic de Storybook, todas son herramientas maravillosas, sin embargo, estoy especialmente interesado en soluciones de código abierto. Y hay muchas implementaciones personalizadas de complementos de código abierto que puedes revisar. Mi favorita es el Visual Regression Tracker. Entonces, el Visual Regression Tracker es básicamente una herramienta para gestionar los resultados de las pruebas visuales, mostrando esas comparaciones de capturas de pantalla, dándote la oportunidad de rechazar o aprobar dichos cambios.

Entonces, el Visual Regression Tracker es básicamente una herramienta para gestionar los resultados de las pruebas visuales, mostrando esas comparaciones de capturas de pantalla, dándote la oportunidad de rechazar o aprobar dichos cambios. Me gusta que sea al menos un poco independiente del marco de automatización. Por lo tanto, puedes usar Playwright con él, puedes usar Cypress para ello e incluso Selenium y otros.

En esta charla utilizaré Cypress, por ejemplo, pero esto no debería ser un obstáculo si no lo utilizas. Así que te mostraré este Visual Regression Tracker y me gusta porque es de código abierto, es una solución autohospedada, por lo que puedo controlar todo lo que quiero. Y solo requiere Docker en tu máquina, y como me gusta Docker, esto es básicamente algo maravilloso que también me gusta.

Entonces, hablemos del Visual Regression Tracker en esta charla. Y para instalarlo, solo lo cubriré brevemente para no perder mucho tiempo, pero podría darte un video más extendido si estás interesado en ello. Así que solo ejecutas... Sí, después de instalar Docker, por supuesto, ejecutas este pequeño script, que instala todo lo que necesitas. Así que tienes este servicio para reiniciarlo. No te preocupes. Lo veremos más adelante. Y desde el punto de vista de tus tareas, es como instalar otra dependencia. En mi caso, instalar o importar un complemento de Cypress. Si quiero usar el Visual Regression Tracker dentro de mis pruebas, solo es un comando personalizado. Entonces, ves el comando cy.track aquí. Como no uso ningún filtro ni ningún parámetro además del título, capturaré la página completa aquí. Pero si lo encadenas justo después de un pequeño elemento como lo hago en el segundo intento, solo haré una captura de pantalla de ese elemento. Y luego se enviará al servicio Visual Regression Tracker. Este servicio se ve así. Así que tienes una pequeña interfaz de usuario que te ayuda con el flujo de aprobación de las capturas de pantalla. Y puedes aceptarla o rechazarla. A la izquierda, verás la línea base. Es decir, la captura de pantalla básica para la comparación. Lo que debería ser correcto. Correcto es, por supuesto, una cuestión de definición que asumimos que es el punto correcto. Y a la derecha, está la nueva captura de pantalla de la nueva implementación de la rama o lo que sea en lo que estés trabajando. Así que ves que hay un menú abierto, que obviamente es un cambio visual en el que debemos decidir. Y a veces puede ser que esas diferencias sean muy pequeñas y difíciles de ver. Si esto sucede, puedes resaltarlo en rojo si quieres.

Entonces, básicamente puedes ver exactamente y de manera muy precisa cuál es la diferencia en esas dos capturas de pantalla. Sí, desde mi experiencia diaria, puedo decir que funciona muy bien cuando se trata de aplicaciones de vista y todos esos ajustes que tienen y todos esos comportamientos que muestran en la visualización diaria. Así que se ajusta bien. Sin embargo, por supuesto, puedes imaginar que hay algunas pequeñas cosas a tener en cuenta porque cuando son leves, habrá sombras, especialmente cuando se trata de la vista y la forma en que renderizan los elementos y cómo funcionan los componentes. Puede haber algunas dificultades y problemas que he experimentado antes.

Y me gustaría echar un vistazo rápido a esos problemas, por supuesto, para no dejarte en el aire aquí. El primer punto es una tendencia típica cuando se trata de testing, y sé que creo que has escuchado antes cuando me quejo de las especificaciones de tiempo, pero también son un problema en las pruebas visuales. Imagina un panel de control del que quieres tomar una captura de pantalla y hay una fecha en él, y ejecutas, por ejemplo, pruebas visuales en una compilación nocturna, por lo que se ejecutarán todas las noches. Entonces tendrás un cambio de fecha de ayer a hoy a mañana. O si lo tienes aún más preciso cuando se trata de esas especificaciones de tiempo, incluso horas, minutos o segundos. Entonces, desencadenarán un cambio en la interfaz de usuario, porque se muestra otro tiempo. Y esto no es algo que necesitemos saber, porque sabemos que el día cambiará, no queremos que nos molesten con esas notificaciones. El punto más fácil, cómo podemos suprimir esas cosas, es congelar el tiempo en el lado del cliente y establecerlo nosotros mismos en una fecha fija o en un tiempo fijo, básicamente falsificándolo. Podemos hacer esto en Cypress por ejemplo con un comando personalizado o el comando cy.clock de Cypress. Entonces, como lo hacemos en este pequeño fragmento de código, congelaremos el sistema siempre a la misma hora en enero de 2018 o algo así y continuaremos como de costumbre a continuación. Entonces, ahora no seremos alertados por cambios de tiempo, pero el tiempo podría ser otro punto que lleva a otro problema, que a menudo se ve en las pruebas de extremo a extremo, pero también en otras.

Se llama inconsistencia. Me encanta usar la historia del niño que gritó lobo de Asok para mostrar qué es la inconsistencia. Solo para resumirlo rápidamente o volver a él rápidamente. Es una historia sobre un niño que cuida un rebaño de ovejas y se aburre y juega bromas a los aldeanos básicamente. Llama a la ayuda y un lobo está atacando sin que haya un lobo, así que en realidad da una falsa alarma. Y cuando los aldeanos vinieron a defenderlo, vinieron por nada y se irán decepcionados. Hasta que haya un verdadero ataque de lobo y ningún aldeano vendrá a defender el rebaño de ovejas. Entonces sí, el niño gritó por un lobo y nadie le cree más. Bueno, una mentira no será creída incluso cuando hable la verdad, eso es básicamente lo que se aprende de eso. Y me gusta usar esta cita para explicar también la inconsistencia. La inconsistencia es una prueba que fallará o pasará sin ningún cambio en el medio. Esto también podría ser el caso de las pruebas visuales. Así que a veces te notificarán un cambio, a veces no, pero no hiciste nada en el medio para causarlo, ¿verdad? Así que sí, realmente necesitamos deshacernos de eso, si no para las pruebas de extremo a extremo, necesitamos deshacernos de eso también para las pruebas visuales. Y cuando se trata de pruebas visuales en específico y para la visualización específica, el principal culpable, al menos en mi experiencia, son los tiempos de carga.

Entonces, básicamente la pregunta es ¿qué sucede si mi sitio web aún se está cargando? ¿Qué sucede si mi elemento aún no ha dejado de renderizarse, o si mi interfaz de usuario aún está cambiando? ¿Realmente estoy tomando la captura de pantalla correcta en el momento adecuado? Realmente necesitamos asegurarnos de hacer exactamente eso. Así que asegurémonos de que nuestra aplicación esté lista para ser capturada, porque de lo contrario podría causar inestabilidad.

Y la solución es bastante simple, porque es la misma solución que usarías para las pruebas también. Utiliza tus afirmaciones conscientemente y úsalas de forma dinámica y no con tiempos de espera fijos. Espera capturas de pantalla consistentes. Espera a que se completen todos los tiempos de carga, que se hayan realizado todos los cambios de renderizado o interfaz de usuario adecuados antes de crear la captura de pantalla. Y sé que soy muy molesto al respecto, pero debería ser una práctica recomendada general no utilizar tiempos de espera fijos, sino esperar hasta que todo esté correctamente hecho.

Otro punto, último pero no menos importante, son los falsos negativos. Y creo que son peligrosos, porque hacen que parezca que tu prueba está fallando porque algo está roto, pero tu prueba falla sin que haya errores presentes. Esto puede ser especialmente el caso de cambios naturales, que no son erróneos, y cambios que no se pueden prevenir. Ya sea, nuevamente, especificaciones de tiempo si tienes un tiempo de solo lectura, que no puedes influir por el cliente. O, mi ejemplo favorito, que me causó algunas pesadillas antes. Es este. Es una imagen en una pantalla de inicio de sesión, tomada de la interfaz de administración de Shopper6, que es básicamente para una tienda en línea. Supongo que todavía es cierto en este momento. Parece bastante inofensivo, pero esta imagen aquí depende del tiempo. Entonces habrá una imagen diferente dependiendo de la hora del día, y se elige al azar de un conjunto de imágenes. Entonces, incluso en el mismo momento, podría ser una imagen diferente, y esto causa todas esas notificaciones de que algo cambió en la aplicación. Y sabemos que es natural, pero no queremos recibir notificaciones nuevamente, falsos negativos.

La solución para esto sería hacer que la prueba ignore los cambios, tal vez usando un umbral de píxeles si se trata de diferencias de renderizado, desenfocándolo o incluso ignorando áreas o elementos. Entonces puedes configurarlo en el servicio de Visual Regression Tracker o en el código si el Visual Regression Tracker no es suficiente para ayudarte allí. Yo uso para esto, uso comandos personalizados propios, donde en realidad tomo la imagen y la establezco en otra imagen de fondo fija que siempre es la misma. Pero debemos tener mucho cuidado cuando se trata de esas interferencias porque esto es en realidad lo que hacemos, interferimos con la aplicación a través de la prueba. Entonces, si haces esto, escribe una prueba separada propia para asegurarte de que, por ejemplo, la imagen o el proceso de selección de imágenes realmente funcione, para no ocultar un error solo porque interfieres con la aplicación en la prueba y documentarlo para que otros desarrolladores en la prueba lo sepan.

Ok, esto se trata básicamente de las mejores prácticas para las pruebas visuales, o las dificultades que encontré. Pero si quieres aprender más sobre las mejores prácticas no solo limitadas a las pruebas visuales, por favor echa un vistazo a la charla de Marco sobre cómo escribir buenas pruebas para aplicaciones UBI porque es un área general y no solo de pruebas visuales. Y si no has tenido la oportunidad de ver esta charla aún, por favor revisa la grabación más tarde, realmente vale la pena. Y junto con esta charla y mi charla, podremos tener pruebas maravillosas. Entonces nuestras pruebas ahora son detectives en este sentido, tal vez Cypress o podría ser cualquier otra cosa, Sherlock Cypress, Sherlock Playwright, Sherlock Selenium o Red Driver, lo que uses porque los hacemos ser un poco más como nosotros, los humanos, haciendo pruebas. Entonces no solo echando un vistazo a las cosas que describimos, sino también fuera del concepto, escribiendo o mirando un poco y esto realmente puede ser un salvavidas porque evita errores causados por efectos secundarios de los que quizás no estés consciente.

Si hay cuatro lecciones que quiero que recuerdes de esta charla, son esas. Siempre intenta darle tamaño a tu prueba, enséñale a mirar más allá del camino dado y haz que actúe como un niño resolviendo un rompecabezas de encontrar las diferencias. Esto se puede lograr a través de pruebas visuales o, simplemente, comparación de capturas de pantalla.

Si no puedes obtener resultados consistentes, está bien interferir con tu prueba. Así que cubre el original con la prueba adecuada para no ocultar problemas, pero está bien hacer esto. Una herramienta como punto de partida puede ser el Visual Regression Tracker, pero también pueden ser otras herramientas mencionadas anteriormente.

De acuerdo, ¿qué más puedo decir además de gracias? Gracias por escucharme. Si tienes preguntas, por favor publícalas aquí, encuéntrame por aquí, búscame en Twitter, LinkedIn, Mastodon, el nombre de usuario se puede encontrar en esta página. Básicamente, donde sea que me hayas encontrado. Y hasta entonces, adiós.