Probando Aplicaciones Vue 3 con Mock Service Worker
From Author:
En esta charla, discutiremos algunas mejores prácticas para probar aplicaciones Vue 3. Exploraremos cómo Mock Service Worker y Vue Testing Library pueden ayudarnos a probar aplicaciones Vue 3 de manera más cercana a una situación de usuario real. Los asistentes saldrán con una comprensión sólida de cómo probar eficazmente sus aplicaciones Vue 3 para garantizar la confiabilidad y mantenibilidad.
This talk has been presented at Vue.js London 2023, check out the latest edition of this JavaScript Conference.
FAQ
Mock Service Worker es una biblioteca que permite simular respuestas del servidor en pruebas de aplicaciones, facilitando la creación de una API simulada para manejar respuestas del servidor y casos extremos. Es especialmente útil en aplicaciones grandes con muchas interacciones API y en entornos de integración continua donde no se pueden hacer llamadas directas a la API.
Probar aplicaciones V3 con Mock Service Worker es crucial para asegurar la calidad del código, detectar errores antes de que lleguen a producción y aumentar la confianza en el código. Esto ayuda a prevenir costos elevados asociados con la corrección de errores en producción y asegura que los componentes funcionen correctamente con diferentes respuestas API.
Para usar Mock Service Worker en una aplicación Vue 3, primero se debe instalar la biblioteca y luego configurarla en el entorno de pruebas, como vitest o Chest. Se crea un directorio de simulación con archivos JSON que simulan respuestas de la API, y se configuran controladores en Mock Service Worker para manejar las respuestas de las solicitudes API en las pruebas.
Para simular respuestas del servidor con Mock Service Worker, se requiere establecer un directorio de simulación que contenga archivos JSON replicando las respuestas de la API deseada. Luego, se configura Mock Service Worker para utilizar estos archivos a través de controladores que gestionan las respuestas según las solicitudes de la aplicación.
Mock Service Worker puede simular respuestas de error configurando controladores que devuelvan estados de error como 403, junto con mensajes de error específicos. Esto permite probar cómo el componente de la aplicación maneja situaciones de error, asegurando que los errores se gestionen adecuadamente en la aplicación.
Mock Service Worker ofrece la ventaja de simular respuestas API sin necesidad de conexiones reales a servidores, lo que es ideal en entornos de integración continua donde las llamadas a APIs externas pueden estar restringidas. Esto facilita realizar pruebas unitarias completas y fiables, mejorando la calidad del software sin depender del acceso a servidores externos.
Video Transcription
1. Testing V3 Applications with Mock Service Worker
Hola. Hoy hablaré sobre cómo probar aplicaciones V3 con Mock Service Worker. Exploraremos cómo usar V3 con Mock Service Worker para mejorar la calidad del código y las pruebas. Probar aplicaciones V3 es crucial para detectar errores temprano y aumentar la confianza en el código. Mock Service Worker es una biblioteca que te permite simular respuestas del servidor en las pruebas, lo que es útil para aplicaciones grandes con interacciones de API. También es excelente para ejecutar pruebas unitarias en un entorno de integración continua. Veamos un ejemplo utilizando Mock Service Worker en una aplicación Vue 3 para simular respuestas de API y probar componentes que interactúan con la API.
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.
2. Setting up Mock Service Worker
Tengo una página que tiene el titular y las diferentes bestias mágicas. Obtengo el contenido real de la API de Storyblocks para mostrar los detalles de la bestia mágica. Para simular la API, creo un directorio de simulación con archivos JSON que replican las respuestas de la API. Luego, configuro el mock service worker y los controladores. Esto implica crear un archivo de configuración y conectar el mock service worker con YDist.
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.
Available in other languages:
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Además de las características principales de Vue3, explicaremos ejemplos de cómo usar bibliotecas populares con Vue3.
Tabla de contenidos:
- Introducción a Vue3
- API de Composición
- Bibliotecas principales
- Ecosistema Vue3
Requisitos previos:
IDE de elección (Inellij o VSC) instalado
Nodejs + NPM
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Nivel de la masterclass: Intermedio
Comments