Probando Aplicaciones Vue 3 con Mock Service Worker

Y vamos directo al grano. Esta charla se basa un poco en Harry Potter. Y descubriremos cómo podemos usar V3 junto con Mock Service Worker para mejorar nuestro código calidad y 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, asegurarte de que esté haciendo lo que debería. Realmente puede ayudarte a detectar errores antes de que se vayan a producción, porque si detectas un error en producción, es mucho más costoso. 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 modificando.

Entonces, ¿qué es Mock Service Worker? Mock Service Worker es una biblioteca muy útil que puedes instalar en tu aplicación y te permite simular respuestas del servidor en tus pruebas. Puedes crear una API simulada y probar cómo tu aplicación está manejando las respuestas del servidor y también manejar casos extremos de respuestas del servidor, que podrían devolver errores. ¿Por qué usarlo? Es realmente importante en aplicaciones grandes que tienen muchas interacciones con la API. Muchas aplicaciones grandes como Storyblock, tienen muchas interacciones con la API y tú quieres asegurarte de que todos estos diferentes componentes estén funcionando como deberían con estas diferentes respuestas que puedes obtener de la API. También es muy útil 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 útil.

Muy bien, veamos el ejemplo que construí y cómo podemos configurarlo. Para comenzar a usar Mock Service Worker, puedes usarlo en una aplicación Vue 3. Necesitas algún tipo de entorno de testing. En este ejemplo, usaremos vitest, pero funciona igual con Chest. Y necesitas Mock Service Worker, que es la biblioteca que está en el núcleo de esta charla. El ejemplo que construí muestra mis bestias mágicas. Tenemos un titular. Tenemos algunas tarjetas con el USB stick, y podemos hacer clic en esas tarjetas y ver más detalles de la bestia mágica. Y todo el contenido aquí se carga desde una API. Tengo un espacio de Storyblock donde configuré algún contenido.

Tengo una página que tiene el titular y las diferentes bestias mágicas. Y luego también puedo ver lo que se devuelve realmente allí. A través de la API de Storyblocks, 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 algún contenido aquí que muestra todos los detalles de esa bestia mágica.

Muy bien. Entonces, empecemos. Lo primero para configurar el mock service worker es que realmente necesitas algún tipo de API, necesitas alguna forma asincrónica de interacción. En mi ejemplo, tengo un componente que realiza una simple solicitud 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 crear un directorio de simulación. En la raíz de nuestro proyecto, podría ser 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 simulación? Si miramos el ejemplo, tenemos una carpeta llamada mocks. Y luego tenemos dos archivos JSON. Así que tenemos el archivo beast JSON, que es la página de inicio. Y luego tenemos el archivo niffler JSON, que es una simulación de la página más específica. ¿Cómo puedes obtener esos JSON? Lo más sencillo es tener tu aplicación y luego verificar en la red qué es lo que realmente devuelve la API. Así que si recargamos eso, mi simulación aquí es básicamente esta solicitud y esta respuesta que tenemos aquí. Así que la historia, simplemente puedo 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 algunas simulaciones que puedan ser utilizadas por el mock service worker, pero también por otras pruebas unitarias que pueden no necesitar el mock service worker.

Luego, el siguiente paso es configurar el mock service worker y configurar algunos controladores. Para configurar el mock service worker, necesitamos crear un archivo de configuración. En la configuración de YDist, podemos configurar algunos archivos de configuración. Entonces proporcionarás la ruta al archivo que configura nuestro entorno de pruebas. Aquí en la configuración de prueba, 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. Antes de todo, después de todo y después de cada prueba, estamos iniciando el servidor, cerrando el servidor y luego restableciendo los controladores después de cada prueba.

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

El siguiente paso aquí es realmente escribir una prueba unitaria para esta página. Cuando escribimos una prueba unitaria, tenemos que pensar, ¿qué hace? Muestra un titular y tiene tres tarjetas con algún contenido. La configuración de la vista es bastante simple. Pero la complejidad aquí radica un poco en la asincronía. Estamos probando un componente asíncrono. Y en Vue, podemos hacerlo envolviéndolo en un componente suspense. Este es un componente bastante nuevo en Vue 3 que puede ayudarnos a lidiar con el comportamiento asíncrono.

Muy bien. Veamos más a fondo. Tenemos ese archivo en nuestro Vue que es asíncrono, como aquí, por ejemplo. Tenemos algo de HTML. Y la parte importante es que tenemos un fetch y debemos esperar la respuesta del fetch. Si observamos ese componente, podemos ver aquí que estamos importando el componente. Y luego lo envolvemos en un componente asíncrono solo para poder probarlo, porque es un componente asíncrono. Y luego podemos escribir la prueba real.

En la prueba real, lo que hacemos es, como es asíncrono, esperamos a que ocurra la solicitud fetch. Cómo puedes hacer eso junto con el mock service worker es creando un espía. Estamos creando un espía en window fetch, y lo llamaremos getSpy. También puedes hacerlo con Axios. Entonces podrías crear un espía que funcione con Axios y haga el mismo tipo de espionaje. Realmente depende de la forma en que estés utilizando para comunicarte con tu API y obtener tus respuestas. El siguiente paso es montar realmente el componente. Obtenemos esta función mount de las utilidades de prueba de Vue. Y luego viene la parte asíncrona. Esperamos a que esta función get, esta función fetch, haya sido llamada una vez. Y luego usamos un ayudante que se llama flush promises. Es un ayudante para las utilidades de prueba de Vue que nos ayuda a asegurarnos de que las promesas se resuelvan. Y finalmente, escribimos las pruebas. Obtenemos el envoltorio para la prueba. Obtenemos el elemento h1.

Obtenemos el texto de eso. Y dijimos, bueno, el texto de mi elemento h1 debería ser 'mi bestia mágica'. 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 tarjetas. Nos aseguramos de que haya exactamente tres tarjetas en esta prueba unitaria. Y eso es básicamente nuestra prueba unitaria conectada con Mock Service Worker. Y es bastante genial porque no tenemos que escribir estas simulaciones extensas y complicadas. Pero con esta configuración global de prueba, cuando se llama a nuestro punto final 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.

Veamos la prueba que escribimos aquí. Un segundo, acabo de ejecutar el archivo. Aquí, tenemos este beforeEach. Monta el componente antes de cada prueba para no tener que volver a escribir esto en cada prueba. Luego tenemos los diferentes casos de prueba. El primero dice que se debe mostrar el encabezado. Deben haber tres tarjetas. Luego también tenemos otro caso de prueba en el que decimos que la segunda tarjeta siempre debe mostrar un elemento if-not que prueba realmente ese contenido que tenemos allí para asegurarnos de que se muestre el contenido de la manera que queremos mostrarlo. Muy bien, 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 controladores que devuelvan algo diferente. Entonces, dentro de nuestras simulaciones, creé un archivo llamado controladores de error. Y los controladores de error se ven muy similares a los controladores que teníamos antes. Nuevamente, utiliza el método rest de MockServiceWorker. Hacemos una solicitud GET al mismo punto final, pero en lugar de devolver un estado de contexto 200, ahora devolvemos un estado de contexto 403. Y luego el punto final devolverá un mensaje de error con 'no permitido'. Eso básicamente simularía un comportamiento en el que dirías que un usuario está llamando a un punto final al que no se le permite llamar a esa entrada. Por ejemplo, un usuario está llamando a un punto final de administrador, pero es posible que el usuario no sea un administrador. Para mostrarte a qué me refiero en el navegador, puedo mostrártelo aquí.

Entonces aquí, si volvemos a mirar la red, recarguemos eso. Y luego podemos bloquear esto. Podemos bloquear esta URL. Y ahora, si recargamos, no puede cargarse porque esta URL está bloqueada. El navegador no nos permite hacerlo. Y luego vemos este error aquí.

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

Entonces, para probar este comportamiento con errores, lo que necesitamos hacer es importar nuestro servidor que estamos usando y 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 se cargue y termine. Y luego escribo el caso de prueba donde digo que mi HTML debe contener esta respuesta de error que se devuelve desde el manejador de errores. El texto que devuelve la API debe mostrarse en mi HTML. Y si miramos estos manejadores de errores, este es el mensaje que se devuelve aquí. Y luego estás probando el mismo componente, el mismo componente asíncrono, con respuestas de API fallidas reales, lo que lo hace aún más claro y asegura que también estamos cubriendo casos donde la API puede fallar. 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 límite. Las API tienen un comportamiento inusual y puedes probar casos de prueba, por ejemplo, donde la API se retrasa 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 punto final que no debería llamar. Por supuesto, el mock service worker no es la única forma de probar. También puedes usar estos MOCs que creamos en pruebas unitarias que no utilizan el mock service worker.

Entonces, para los componentes que tal vez no llamen a una API, solo sean componentes regulares que no sean asíncronos. Para las unidades más pequeñas, realmente puedo recomendar el uso de la biblioteca de pruebas. Es un envoltorio muy bueno alrededor de las utilidades de prueba de vista que pueden probar incluso mejor para la 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 probar estos comportamientos de clic o comportamientos de campo de entrada para asegurarse de que sus componentes se comporten como deberían para la interacción del usuario.

Y les mostraré un caso rápido de nuestro ejemplo. Así que desactivemos el bloqueo aquí. Si vamos a nuestro elemento aquí, es un componente simple que recibe una propiedad. Y ahora queremos probar ese componente y tal vez probar este comportamiento de clic que tenemos aquí en los botones, o que tenemos un botón. Les mostraré la prueba real.

Entonces, este es nuestro componente. Es un componente de vista simple con mucho HTML. Y básicamente solo recibe una propiedad llamada Bloque. Eso es muy común en aplicaciones que usan Storyblock. Y luego todo lo que se muestra aquí se basa en esta propiedad de bloque que está recibiendo. Y luego aquí podemos ir a la prueba para este componente. Y aquí vemos que estamos importando las funciones de renderización de pantalla y eventos de la biblioteca de pruebas de vista. Entonces, esas son las funciones principales que necesitarías al probar con esta biblioteca. También estoy importando la configuración 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 envoltorio asíncrono porque no es un componente asíncrono que está esperando alguna respuesta de API. Es solo un componente simple. También estoy importando esta simulación que creé al principio donde simplemente copié la respuesta que obtuve del servidor. Luego creo la propiedad real que se pasa al componente. Entonces, lo que se pasa al componente está dentro de toda esa simulación. Así que obtengo la parte específica de la simulación que necesito pasar al componente. Luego renderizo el componente real. Paso el contenido, la simulación, a ese componente. Y luego puedo tener diferentes casos de prueba.

Aquí estoy probando que el nombre de la pieza mágica, la descripción y la imagen estén presentes. También puedo hacer pruebas. Y lo bueno de esta biblioteca es que puedo probar mediante el texto alternativo. Puedo probar mediante marcadores de posición. Y esto puede ser realmente útil para hacer que tu aplicación sea más accesible, ya que no solo realizamos pruebas para pruebas específicas, sino para atributos HTML reales.

Y finalmente, también puedo probar algunas interacciones. Aquí estoy diciendo que quiero tener exactamente un botón con el texto. Y luego, cuando hago clic en ese botón, quiero asegurarme de que este componente emita el evento específico. Esto básicamente prueba este comportamiento de que este componente emite un evento cuando hacemos clic en él. Y ahora, si alguien fuera a este componente y eliminara este botón, nuestra prueba unitaria fallaría. Veríamos que algo salió mal porque ya no cumple con este comportamiento de botón. Lo mismo sucedería si esta persona cambiara este botón por un div. La prueba unitaria fallaría porque hemos sido muy específicos al decir que 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 puedes ver aquí, no está utilizando un mock service worker. No es asíncrono, pero está utilizando las mismas simulaciones que también usamos 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. Entonces, si todas las pruebas están utilizando el mismo tipo de simulaciones y si mi API está cambiando, también tengo que cambiar las simulaciones. Pero puedo asegurarme de que mis componentes y mis componentes cuando los estoy probando realmente estén funcionando con todas las cosas que provienen de mi API.

De acuerdo, eso es básicamente todo. Tengo algunos recursos más. Mockserviceworker tiene una documentación realmente buena. La biblioteca de pruebas es realmente excelente para probar componentes simples y probar interacciones. Vue.js también tiene muchas guías excelentes sobre cómo trabajar con comportamiento asíncrono, cómo trabajar con suspense y también cómo probar el comportamiento asíncrono porque en realidad no es tan fácil. Y sí, también puedes usar Storyblock para crear tus propias APIs. Y sí, fue realmente divertido hacerlo y aprenderlo y configurarlo. Espero que uses este repositorio para probarlo en tu propia aplicación Vue 3. Muchas gracias por escuchar. ♪♪♪