Pruebas de Aplicaciones Vue 3 con Mock Service Worker

Hola. Quiero hablarles hoy sobre las pruebas de aplicaciones V3 con mux-serviceworker. Soy Lizzie. Soy arquitecta frontend en Storyblock. Puedes encontrarme en Twitter, pero lo más importante, puedes encontrar todos los ejemplos que hice para esta charla en este repositorio de GitHub.

Y vamos a sumergirnos directamente en ello. Así que esta charla está basada un poco en Harry Potter. Y averiguaremos cómo podemos usar V3 junto con mux-serviceworker para mejorar nuestra calidad de código y para probar de una manera mejor y más integrada.

Entonces, ¿por qué es importante probar aplicaciones V3? Es realmente crucial para perfeccionar tu código, para asegurarte de que está haciendo lo que debería. Realmente puede ayudarte a detectar errores antes de que lleguen a producción, porque si detectas un error en producción, es mucho más caro. Así que cuanto antes detectes los errores, mejor. Y realmente puede ayudar a aumentar la confianza en tu código y en el código que estás escribiendo y también en el código que estás cambiando.

Entonces, ¿qué es Mock Service Worker? Mock Service Worker es una biblioteca realmente buena que puedes instalar en tu aplicación y te permite simular respuestas del servidor en tus pruebas. Así que puedes crear una API simulada y puedes probar cómo tu aplicación realmente maneja las respuestas del servidor y también manejar casos extremos de respuestas del servidor, que podrían devolver errores. ¿Por qué usarías eso? Es realmente importante en aplicaciones grandes que tienen muchas interacciones de API. Así que muchas aplicaciones grandes como Storyblock, tienen muchas interacciones de API y tú quieres asegurarte de que todos estos diferentes componentes, realmente están funcionando como deberían funcionar con estas diferentes respuestas que puedes obtener de la API. También es realmente bueno si ejecutas tus pruebas unitarias en un entorno de integración continua. Por ejemplo, ejecutas tus pruebas unitarias en GitHub Actions, y dentro de ese entorno de integración continua no puedes llamar a la API. Así que necesitas simular la API y ejecutar las pruebas unitarias con respuestas simuladas reales. Y ahí es donde usar mock service worker es realmente bueno.

Muy bien, veamos el ejemplo que construí y cómo podemos configurarlo realmente. Para comenzar a usar mock service worker, puedes comenzar a usarlo en una aplicación Vue 3. Necesitas algún tipo de entorno de pruebas. Así que en este ejemplo, usaremos vitest, pero funciona con Chest de la misma manera. Y necesitas mock service worker, que es la biblioteca que está en el núcleo de esta charla. Así que el ejemplo que construí, está mostrando mis bestias mágicas. Tenemos un titular. Tenemos algunas tarjetas con el USB stick, y podemos hacer clic en esas tarjetas y ver algunos más detalles de la bestia mágica. Y todo el contenido aquí, se carga desde una API. Así que tengo un espacio de story block donde configuré algo de contenido.

Tengo una página que tiene el titular y la diferente bestia mágica. Y luego también puedo ver lo que realmente se devuelve allí. Así que a través de la API de story block, obtengo el contenido real que luego puedo usar para mostrar mi contenido, lo mismo para las páginas más específicas. Así que tengo una bestia mágica y luego tengo algo de contenido aquí que muestra todos los detalles de esa bestia mágica.

Muy bien. Así que comencemos. Lo primero para hacer una configuración de mock service worker es que realmente necesitas algún tipo de API, necesitas algún tipo de forma asincrónica de interacción. Así que en mi ejemplo, tengo un componente que obtiene, simplemente hace un fetch simple a la API de Storyblocks y que tiene todas las respuestas. Y luego a partir de esa respuesta, construyo la página real que vemos. Y la parte importante aquí es que ahora necesitamos simular la API. Así que nuestro primer paso es realmente crear un directorio de mock. En la raíz de nuestro proyecto, también podría estar en otro lugar, pero lo haré en la raíz. Y luego configuramos el mock service worker.

Entonces, ¿qué quiero decir con un directorio de mock? Si miramos el ejemplo, tenemos una carpeta allí que se llama mocks. Y luego tenemos dos archivos JSON. Así que tenemos el beast JSON, que es la página de inicio. Y luego tenemos el niffler JSON, que es un mock de la página real, más específica. ¿Cómo puedes obtener esos JSONs? Lo más simple es tener tu aplicación, y luego verificar en la red lo que realmente está siendo devuelto por la API. Así que si recargamos eso, mi mock aquí es básicamente esta solicitud y esta respuesta que tenemos aquí. Así que la historia, podría simplemente copiar eso y pegarlo aquí en mi archivo beast JSON. Así que este es solo una copia de lo que tenía en esa página. Así que esa es realmente la primera parte, tener algunos mocks que puedan ser utilizados por el mock service worker, pero también por otras pruebas unitarias que podrían no necesitar el mock service worker.

Luego, el siguiente paso es realmente configurar el mock service worker y configurar algunos handlers. Así que para configurar el mock service worker, necesitamos realmente crear un archivo de configuración. Así que en la configuración de white disk, podemos configurar algunos archivos de configuración. Así que proporcionarás la ruta al archivo que está configurando nuestro entorno de pruebas. Luego aquí en la configuración de pruebas, tengo este archivo index.js que tiene mi configuración global de pruebas. Así que esa es la configuración que se utiliza en todas las pruebas que estoy escribiendo. También tengo algunas otras cosas aquí, pero la parte importante está aquí, el archivo de configuración del mock service worker, donde conecto el mock service worker con YDist. Así que antes de todo, después de todo, y después de cada prueba, estamos iniciando el servidor, estamos cerrando el servidor, y luego estamos restableciendo los handlers después de cada prueba.

Y luego el servidor real que estamos creando. Así que esa es la parte central. Estamos importando de mock service worker y le estamos proporcionando algunos handlers. Los handlers son la parte central de configurar mock service worker. Y lo que hacen los handlers es que conectan una REST API, o también puedes hacer una GraphQL API con un método específico. Así que dices, por ejemplo, tengo una solicitud GET, una solicitud REST GET que causa el endpoint API store block, lo que sea. Y cuando eso sucede, quiero devolver el estado 200 y luego por favor devuelve un JSON de este mock que acabamos de crear. Así que estamos devolviendo una respuesta mock y podemos usar eso luego en nuestras pruebas unitarias. Hacemos lo mismo para la página más específica de esa bestia mágica. Así que aquí realmente estamos conectando la respuesta de ejemplo JSON con el endpoint y esta conexión nos ayudará a escribir luego las pruebas unitarias. Así que no necesitas mucho más que eso, configurar el servidor y configurar los handlers y luego ya podemos empezar a volar y escribir nuestra primera prueba unitaria.

Así que el siguiente paso aquí es realmente escribir una prueba unitaria para esta página. Al escribir una prueba unitaria, tienes que pensar, bueno, ¿qué hace? Muestra un titular y tiene tres tarjetas que tienen algún contenido. Así que la configuración de la vista es bastante simple. Pero la complejidad aquí viene un poco con la asincronía. Así que estamos probando un componente asincrónico. Y en Vue, podemos hacer eso envolviéndolo en un componente suspense. Así que este es un componente bastante nuevo en Vue 3 que puede ayudarnos a lidiar con el comportamiento asincrónico.

Muy bien. Vamos a profundizar más en ello. Así que tenemos ese archivo en nuestro Vue que es asincrónico, como aquí, por ejemplo. Tenemos algo de html. Y la parte importante es que tenemos un fetch, y tenemos que esperar la respuesta del fetch. Si miramos en ese componente, podemos ver aquí que estamos importando el componente. Y luego lo estamos envolviendo en un componente asincrónico solo para que podamos probarlo, porque es un componente asincrónico. Y luego podemos escribir la prueba real.

Así que en la prueba real, lo que hacemos es, dado que es asincrónico, esperamos a que se realice el fetch. Cómo puedes hacer eso junto con mock service worker es creando un espía. Así que estamos creando un espía en window fetch, y lo llamaremos getSpy. Puedes hacer eso también con Axios. Así que podrías crear un espía que funcione con Axios que haga el mismo tipo de espionaje. Realmente depende de qué manera estás usando para hablar con tu API y obtener tus respuestas. El siguiente paso es realmente montar el componente. Así que obtenemos esta función mount de view test utils. Y luego viene la parte asincrónica. Esperamos a que esta función get, este fetch haya sido llamada una vez. Y luego usamos un helper llamado flush promises. Es un helper para view test utils para ayudarnos a asegurarnos de que las promesas se resuelvan. Y luego finalmente, escribimos las pruebas. Así que obtenemos el wrapper para la prueba. Obtenemos el elemento h1.

Obtenemos el texto de eso. Y dijimos, bueno, el texto de mi elemento h1 debería ser my magical beast. Y luego encontramos todos los elementos que tienen la clase VA card. Y decimos, bueno, debería haber tres elementos que tengan la clase VA card. Así que son tres clases. Así que se asegura de que haya exactamente tres tarjetas en esta prueba unitaria. Y eso es básicamente ya nuestra prueba unitaria conectada con mock service worker. Y es bastante genial porque no tenemos que escribir estos mocks realmente extensos. Pero con esta configuración global de prueba, cuando nuestro endpoint es llamado aquí con el window fetch, automáticamente obtendrá este JSON que tenemos aquí. Y el componente funciona como funcionaría también en el entorno real. Y luego, cuando escribimos la prueba, podemos asegurarnos de que la configuración de ese componente sea realmente como debería ser.

Así que veamos la prueba que escribimos aquí. Un segundo, solo ejecuto el archivo. Así que aquí, tenemos este before each. Así que monta el componente antes de cada prueba para que no tengamos que reescribir esto en cada prueba. Y luego tenemos los diferentes casos de prueba. El primero dice, bueno, el encabezado debería mostrarse. Debería haber tres tarjetas. Luego también tenemos otro caso de prueba donde decimos, bueno, la segunda tarjeta siempre debería mostrar un elemento if-not que prueba realmente para ese contenido que tenemos allí para asegurarnos de que el contenido se muestre de la manera que queremos mostrarlo. Muy bien, y sí, eso ya está conectado.

Y ahora viene la parte interesante porque MockServiceWorker, no solo puede simular estas respuestas positivas, sino que también puede simular respuestas de error o retrasos más largos. Y podemos hacer eso simplemente creando nuevos handlers que realmente devuelvan algo más. Así que dentro de nuestros mocks, creé un archivo que se llama error handlers. Y error handlers se ve muy similar a los handlers que teníamos antes. Nuevamente, está usando el método rest de MockServiceWorker. Hacemos una solicitud GET al mismo endpoint, pero en lugar de devolver un estado de contexto 200, ahora estamos devolviendo un estado de contexto 403. Y luego el endpoint devolverá un mensaje de error con not allowed. Y eso básicamente simularía un comportamiento donde dirías que un usuario está llamando a un endpoint que no está permitido para llamar a esa entrada. Por ejemplo, un usuario está llamando a un endpoint de administrador, pero el usuario podría no ser un administrador. Para mostrarte lo que quiero decir en el navegador, puedo mostrarte eso aquí.

Así que aquí, si miramos la red nuevamente, recarguemos eso. Y luego podemos bloquear esto. Podemos bloquear esta URL. Y ahora si recargamos, no puede cargar, porque esta URL está bloqueada. El navegador no nos lo permite. Y luego vemos este error aquí.

Así que adapté mi componente para ser realmente capaz de manejar este tipo de respuesta de error. Así que dentro de mi vista de inicio, se ha vuelto un poco más complicado donde verifiqué la respuesta. Verifiqué el estado de la respuesta. Y si no está en 200, lanzo un error. Y este error se muestra dentro de mi página. Y ahora puedo escribir la prueba para ello.

Así que para probar este comportamiento con errores, lo que necesitamos hacer es importar nuestro servidor que estamos usando que está activo. Y necesitamos importar nuestros manejadores de error que tienen las respuestas de manejo de errores reales. Y luego puedo escribir un nuevo conjunto de pruebas para las solicitudes fallidas. Y puedo decir, por favor usa el servidor con los manejadores de error en lugar de los otros manejadores regulares para ver cómo se comporta mi componente con una respuesta de API fallida. Luego espero a que eso se cargue y termine. Y luego escribo el caso de prueba donde digo, mi HTML debería contener esta respuesta de error que se devuelve del manejador de errores. Así que el texto que la API está devolviendo debería mostrarse en mi HTML. Y si miramos estos manejadores de error, este es el mensaje que se devuelve aquí. Y luego estás probando el mismo componente, el mismo componente asincrónico, con respuestas de API realmente fallidas lo que lo hace aún más claro y asegura que también estamos cubriendo casos donde la API podría estar fallando. Así que esto es realmente genial. Y esto es algo que es bastante difícil de hacer cuando tienes que escribirlo tú mismo y no tienes el mock service worker. Así que tienes que hacer mucho más sin el mock service worker para obtener este tipo de comportamiento de prueba. Así que es realmente, realmente poderoso. También puedes probar otros casos extremos. Así que las APIs tienen comportamientos inusuales, y tú puedes probar casos de prueba, por ejemplo, donde la API se retrasa por dos segundos. O puedes probar casos donde tienes algún mensaje de error personalizado o alguna respuesta personalizada porque ocurrió algún caso personalizado como un usuario llamando a un endpoint que no debería estar llamando. Por supuesto, MOC service worker no es la única manera de probar. Puedes usar estos MOCs que creamos también en pruebas unitarias que no están usando el MOC service worker.

Así que para componentes que no están tal vez llamando a una API, son solo componentes regulares que no son asincrónicos. Para las unidades más pequeñas, realmente puedo recomendar usar la testing library. Es un contenedor realmente agradable alrededor de las utilidades de prueba de Vue que puede probar incluso mejor para accesibilidad. Puede probar si los elementos correctos están en la pantalla. Puede probar la interacción del usuario. Así que es realmente bueno para hacer estos comportamientos de clic o comportamientos de campo de entrada para asegurarse de que tus componentes se comporten como deberían para la interacción del usuario.

Y te mostraré un caso rápido de nuestro ejemplo. Así que desactivemos el bloqueo aquí. Así que si vamos a nuestro elemento aquí, es un componente simple que recibe un prop. Y ahora queremos probar esos componentes y tal vez probar este comportamiento de clic que tenemos aquí en los botones, o que tenemos un botón. Te mostraré la prueba real.

Así que este es nuestro componente. Así que es un componente de Vue simple con mucho HTML. Y básicamente solo recibe un prop llamado Block. Eso es muy común en aplicaciones que usan Storyblock. Y luego todo lo que se muestra aquí se basa en este prop block que está recibiendo. Y luego aquí podemos ir a la prueba de este componente. Y ves aquí que estamos importando las funciones render screen y fire event de la testing library de Vue. Así que esas son las funciones principales que necesitarías cuando pruebas con esta biblioteca. También estoy importando la config porque quería que recibiera parte de la configuración global que ya había configurado. Y luego importo el componente.

Aquí no necesito este contenedor async porque no es un componente asincrónico que está esperando alguna respuesta de API. Es solo un componente simple. Y también estoy importando este mock que creé al principio donde solo copié la respuesta que obtuve del servidor. Luego creo el prop real que se pasa al componente. Así que lo que se pasa al componente está dentro de todo ese mock. Así que obtengo la parte específica del mock que necesito para pasarlo al componente. Luego renderizo el componente real. Paso el contenido, el mock, a ese componente. Y luego puedo tener los diferentes casos de prueba.

Así que aquí estoy probando que el nombre de la pieza mágica, la descripción y la imagen estén ahí. También puedo probar. Y eso es lo genial de esta biblioteca es que puedo probar por texto alternativo. Puedo probar por marcador de posición. Y esto puede ser realmente útil para hacer tu aplicación más accesible porque no solo hacemos pruebas para pruebas específicas, sino para atributos HTML reales.

Y finalmente, también puedo probar alguna interacción. Así que aquí estoy diciendo que quiero tener exactamente un botón con el texto. Y luego, cuando hago clic en ese botón, quiero estar seguro de que este componente emitió el evento específico. Así que esto básicamente prueba este comportamiento de que este componente está emitiendo un evento cuando hacemos clic en él. Y ahora si alguien entrara en este componente y eliminara este botón, entonces nuestra prueba unitaria fallaría. Y veríamos, bueno, algo salió mal porque ya no está cumpliendo con este comportamiento del botón. Lo mismo sucedería si esta persona cambiara este botón por un div. La prueba unitaria fallaría porque hemos sido realmente específicos al decir, bueno, debería haber un botón con ese nombre que debería emitir exactamente este evento. Y esto nos ayuda a asegurarnos de que nuestra aplicación no se rompa.

Y como ves aquí, no está usando un mock service worker. No es asincrónico, pero está usando los mismos mocks que también estamos usando junto con el mock service worker. Y eso es realmente útil porque tenemos un lugar donde definimos el punto de interacción entre la API y la aplicación. Así que si todas las pruebas están usando el mismo tipo de mocks y si mi API está cambiando, también tengo que cambiar los mocks. Pero puedo asegurarme de que mis componentes y mis componentes cuando los estoy probando están realmente trabajando con todas las cosas que vienen de mi API.

Muy bien. Eso es básicamente todo. Tengo algunos recursos más. Así que mockserviceworker tiene una documentación realmente buena. La testing library es realmente genial para probar componentes simples y probar interacciones. Vue.js también tiene muchas guías geniales sobre cómo trabajar con comportamiento asincrónico, cómo trabajar con suspense, y también cómo probar el comportamiento asincrónico porque en realidad no es tan fácil. Y sí, también puedes usar un story block para crear tus APIs. Y sí, fue realmente divertido de hecho hacer y aprender y configurar. Y espero que uses este repositorio para probarlo en tu propia aplicación Vue 3. Muchas gracias por escuchar.