Pruebas Visuales: Optimiza Storybook y Gana

Hola, soy Ruben, y soy el ingeniero de soluciones líder en Chromatic, y somos los mantenedores de Storybook. Así que, voy a empezar con una historia. Este eres tú, y las pruebas de UI testing son difíciles. Hay tantos estados y variantes, responsividad, estados de carga, todo es un poco confuso y todo se quema hasta el suelo. Bueno, esperemos que no, pero eso es lo que termina sucediendo a veces.

Así que, realmente, hay dos problemas. Digamos que esta es tu tercera semana seguida que recibes una llamada y la UI está rota en el sitio web y necesitas ir a arreglarlo, o peor aún, el sitio está completamente caído. Ahora, eso no es divertido para nadie. Y luego, por otro lado, cuando no te llaman durante el fin de semana para solucionar problemas de UI, estás lidiando con pruebas de integración inestables, y eso tampoco es divertido. Entonces, ¿cuándo te diviertes en tu trabajo? No parece que te estés divirtiendo en absoluto.

Idealmente, nos alejamos de ese estado complicado y lo quemamos para realmente simplificarlo. Solo quieres saber cómo se ve tu UI y compararlo con cómo se ve ahora. Y storybook es la primera parte de la solución a ese problema. Storybook te permite construir tu UI de forma aislada, y lo simplifica porque no tienes que preocuparte por la lógica del back-end y las llamadas a la API, bases de datos, nada de eso. Solo estás construyendo tu UI. Y funciona. Así que, acelera el proceso. Y luego, chromatic es el otro lado de eso, donde crea pruebas automatizadas de tu UI. Ahora, ¿cómo se ve eso? Te voy a mostrar un ejemplo.

Así que, aquí tenemos una aplicación llamada Mealdrop, y es un clon de Uber Eats. Storybook te permite crear todo tipo de componentes. Tienes tus componentes atómicos, por ejemplo, este botón, y storybook tiene controles que son esencialmente las props de tu componente y te permite jugar y prototipar cosas todo dentro del entorno de storybook en tu navegador. Y también puedes crear componentes a nivel de página. Por ejemplo, como la página de inicio. O una página de detalles de restaurante. Y esto tiene todo en él, ¿verdad? Toda la estructura de tu página. Y la mejor parte de ello es que está aislado, y no tienes que preocuparte por datos inconsistentes o algo por el estilo. Ahora, eso resuelve el primer problema. Pero no resuelve el segundo problema de cómo diablos... ¿Qué haces para asegurarte de que tu UI no esté fallando en producción? Ahí es donde entra chromatic.

Chromatic toma tu storybook construido estáticamente, y compara tu UI. Y cómo lo hace es que primero creas un estado definido o una línea de base de cómo se ve tu UI o cómo esperas que se vea. Y luego, cada vez que cambias tu código después de eso, tomará una nueva imagen o una instantánea y la comparará con la instantánea antigua. Y cada vez que hay un cambio, recibes una notificación dentro de chromatic, y luego ya no tienes que preocuparte por testing manualmente, comprobando diferentes navegadores, diferentes vistas, pidiendo a tu compañero de trabajo su teléfono Android y comprobando si funciona en eso. Sí, he hecho todo eso. No es divertido. Así que lo realmente interesante aquí es que chromatic puede ser tan específico o tan laxo como quieras que sea. Por defecto, es realmente estricto. Así que aparentemente, a simple vista, aquí no cambió nada. Se ve exactamente igual, ¿verdad? Si te enfocas, antes de que incluso vaya a la sección que está resaltada, chromatic sabe que hay una ligera diferencia en la imagen de la hamburguesa. Y si te enfocas en esa hamburguesa, hay ligeros cambios de píxeles. Y así detectará ese cambio visual menor que no notarías con tus ojos. Quiero decir, podrías. Mis ojos no son tan buenos. Así que me lo perdería. Ahora esto me lleva a mi segundo punto. ¿Cómo resolvemos eso en un... ¿Cómo tomas una UI dinámica y tomas una instantánea estática y haces que funcione de manera consistente para que no tengas que arreglar todas estas pruebas cada vez? Y ahí es donde Storybook entra con chromatic. Así que tienes estas páginas. Si carga. Ahí vamos. Así que la razón por la que esa imagen cambia es porque tienes... Así que estamos cargando esta imagen desde Unsplash, que es un recurso de red. Y Unsplash puede cambiar esa imagen en cualquier momento por cualquier razón. La URL es exactamente la misma. Así que por lo que sabemos, nada cambió con esta imagen. Pero realmente sí lo hizo. Y podría ser más drástico que esto. Pero afortunadamente en este caso no lo es. Son solo algunos píxeles menores.

Y podrías simplemente aprobarlo y seguir adelante. Bueno, eso no siempre es el caso. Y entonces el mejor enfoque para esto... En realidad hay varios enfoques. Si tienes la opción de cargar imágenes estáticamente, entonces lo que recomendamos es cargar tus imágenes dentro de Storybook como un activo estático. De esa manera tus instantáneas de compilación por compilación son siempre consistentes. Porque siempre estás obteniendo los mismos data y siempre obteniendo los mismos activos.

Ahora, a veces no tienes esa opción. Tienes tal vez un conjunto de fuentes desde un CDN. Y eso es para que puedas obtener capacidad de respuesta y cargar diferentes imágenes. Y en esos casos, tenemos que ser un poco más tácticos sobre cómo hacemos eso. Así que hay un par de opciones. Puedes simular completamente los data que están entrando y pasar los data simulados a tu historia. O puedes hacer una combinación donde simulas la solicitud de red con algo como un trabajador de servicio simulado. Lo que aprendimos hoy. Y si haces eso, anulas la solicitud de red. Así que todavía estás obteniendo una solicitud. Pero estás diciendo, oye, cuando esta solicitud llegue, entrega este activo en su lugar. Y luego la tercera opción es usar las funciones de reproducción incorporadas en Storybook para esperar... Puedes crear una función de utilidad para esperar a que todas las imágenes se carguen. Y luego poner eso en la función de reproducción. Así que le estás diciendo a la prueba que espere hasta que tu UI esté en un estado en el que esperas que esté.

Ahora, hablando de pruebas de interacción... Lo realmente interesante de ellas es que puedes simular un flujo de trabajo de usuario en Storybook mismo. Así que voy a ir a estas plantillas. Y oh, lo siento. Los flujos de usuario. Y como... Para que la página de éxito funcione en un entorno no simulado, tendrías que tomar tantos pasos para que funcione. Pero aquí he definido 22 pasos de interacción con afirmaciones y declaraciones de expectativas que tienen que pasar para que esta prueba pase en CI.

Por lo tanto, cubre todo tu caso de uso de principio a fin. E incluso lo ralentizaré para que puedas ver lo que sucede. Así que si vuelvo a ejecutar esta prueba de interacción, comienza desde el principio y pasa por todo el flujo de trabajo del usuario para asegurarse de que esto se renderiza correctamente cada vez. Y estás testing ese estado final de la UI que esperas que tu usuario vea cuando ejecutan este proceso.

Ahora, lo último que quiero mencionar es que las pruebas de interacción no son solo para los flujos de trabajo de los usuarios. También puedes escribir pruebas de interacción para componentes más complejos. Así que en este caso, tenía un desplegable de navegación en el que estaba trabajando. Y estaba usando Daisy UI y remix. Y no podía cerrar el modal. Y seguía intentándolo en mi aplicación y reiniciándola y volviéndola a iniciar. Y nada funcionaba. Yo estaba, como, oh, sí, trabajo en Storybook. ¿Por qué no tengo un Storybook para esto? Así que inicié un Storybook, escribí una prueba de interacción hasta que la pasé y descubrí el elemento con el que necesitaba interactuar para que se cerrara. Y lo arreglé. Y así que ahora no solo tengo un caso de prueba, un caso de prueba vivo que probará que mi modal se abre, sino que puedo extender eso en mi prueba de cierre de menú. Lo cual toma todo el código que ya he escrito, añade un par de pasos más para cerrar el modal. Y ahora tengo una prueba para ambos casos.

Y eso es todo. Gracias.