Más allá de la simulación de API

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

La simulación es una de las mejores técnicas para separar las preocupaciones durante las pruebas. Cuando se trata de la simulación de API, tendemos a o bien simular un cliente de solicitud o reemplazarlo por completo con una contraparte simulada. Lo que estamos haciendo es alterar el sistema probado para que realice solicitudes a una fuente diferente, o que no las realice en absoluto. Eso se debe principalmente a que no había una opción mejor. Hasta ahora.


En esta charla, repasaremos cómo utilizar eficientemente la simulación de API que mantiene la integridad de tu aplicación JavaScript y da como resultado pruebas más confiables. Además, ilustraré cómo reutilizar las mismas simulaciones en diferentes niveles de prueba, así como durante el desarrollo y la depuración. Todo eso con una sola herramienta en tu arsenal.

This talk has been presented at TestJS Summit - January, 2021, check out the latest edition of this JavaScript Conference.

FAQ

La simulación de API permite sustituir la comunicación real de API, como las solicitudes HTTP, por alternativas controladas para probar diferentes aspectos de una aplicación. Es fundamental para enfocar las pruebas en componentes específicos sin la interferencia de otros módulos o servicios externos.

Los dos principios fundamentales son probar como un usuario, asegurando que las pruebas reflejen el uso real del software, y establecer límites claros para determinar el enfoque y la extensión de las pruebas, como pruebas unitarias, de integración o de extremo a extremo.

Las desventajas incluyen la necesidad de mantener operativo el servidor simulado, el riesgo de que las pruebas no reflejen la realidad si hay errores en la configuración de las URL, y la posibilidad de que las pruebas pasen en el entorno de CI mientras fallan en producción debido a divergencias en el código.

MSW utiliza Service Workers para interceptar solicitudes y proporcionar respuestas simuladas, permitiendo que las solicitudes reales sean parte del proceso de prueba. Esto asegura que las pruebas reflejen fielmente el comportamiento en producción, eliminando divergencias y proporcionando una conformidad completa con las especificaciones.

MSW es útil para testing, desarrollo, depuración y prototipado. Permite simular respuestas de API cuando el backend no está disponible o en desarrollo, y facilita la depuración al permitir la manipulación de respuestas para identificar problemas.

Los retos incluyen la limitación en el acceso a ciertos objetos como window o DOM, la posible obsolescencia de los workers, y la confusión que puede generar al manejar solicitudes de diferentes proyectos en la misma URL durante el desarrollo.

Artem Zakharchenko
Artem Zakharchenko
25 min
15 Jun, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla de hoy discute la simulación de API y su papel en las pruebas. El orador explora las ventajas y desventajas de la simulación en el lado del servidor y del cliente, e introduce el uso de los trabajadores de servicio para la simulación. La biblioteca MockServiceWorker (MSW) se presenta como una solución que aprovecha los trabajadores de servicio para interceptar las solicitudes y proporcionar respuestas simuladas. MSW es independiente del cliente, ampliamente utilizado y ofrece muchas características. El orador también menciona mejoras próximas y anima a los usuarios a probar MSW y proporcionar comentarios.
Available in English: Beyond API Mocking

1. Introducción a la Simulación de API

Short description:

Hola a todos. Gracias por unirse. Hoy me gustaría hablar con ustedes sobre pruebas y específicamente sobre la simulación de API y el papel que desempeña en ellas. ¿Por qué escribimos pruebas? Bueno, escribimos pruebas para ganar confianza y asegurarnos de que el software que construimos sea funcional. Para ganar esa confianza, debemos probar como un usuario y establecer límites claros. La simulación es una herramienta que ayuda a distribuir estos límites.

♪♪ Hola a todos. Gracias por unirse. Espero que estén sanos y bien, y me encantaría hablar sobre la simulación de API. Mi nombre es Artem, y soy un ingeniero de JavaScript que tiene un gran amor por el código abierto. He estado contribuyendo al código abierto durante más de cinco años, durante los cuales tuve la gran suerte de ser el autor de más de 20 paquetes que en este momento tienen más de ocho millones de descargas en NPM. Y hoy me gustaría hablar con ustedes sobre pruebas y específicamente sobre la simulación de API y el papel que desempeña en ellas.

Pero antes de comenzar, me gustaría hacerles una pregunta. ¿Por qué escribimos pruebas? Bueno, ciertamente no las escribimos para obtener cobertura de código. Puede ser útil en ocasiones, pero desafortunadamente, no significa que nuestro producto funcione o funcione bien. No escribimos pruebas para verificar cada pequeño trozo de lógica que hemos escrito porque eso sería probar nuestro código en lugar de probar la intención detrás del código, lo cual no deberíamos hacer. Creo que escribimos pruebas para ganar confianza, para asegurarnos de que el software que construimos sea funcional y que nuestros clientes lo disfruten y lo amen. Y para ganar esa confianza a través de las pruebas, debemos seguir dos principios. Y el primero es probar como un usuario. Y el usuario aquí no necesariamente significa cliente. Por supuesto, si tienes un sitio web de comercio electrónico y quieres verificar los escenarios de éxito en diferentes páginas, realizarás acciones de usuario allí. Pero digamos que estás escribiendo una prueba para una función o una clase. Entonces el usuario para esa clase sería otro desarrollador. Entonces necesitas poner sus expectativas contra tu clase y escribir tu prueba siguiendo esas expectativas. Me gusta esta cita de Kenzie Dots que dice, cuanto más se parezca tu prueba a la forma en que se usa tu software, más confianza te pueden dar. Y creo que resume este principio de manera bastante brillante. El otro principio que puede brindarnos más confianza durante las pruebas es establecer límites claros. Creo que estás bastante familiarizado con esto porque esta es la razón por la que tenemos diferentes niveles de pruebas. Entonces, cuando queremos enfocarnos en una sola unidad de código, escribimos pruebas unitarias, luego tal vez quieras verificar que las piezas encajen bien y hacemos algunas pruebas de integración y podemos terminar con pruebas de extremo a extremo para verificar todo el sistema. Y veo la simulación como una herramienta que distribuye estos límites. Permítanme darles un ejemplo. Digamos que tenemos este cuadrado naranja y queremos probarlo. Ahora, en una aplicación real, este cuadrado naranja probablemente haga varias cosas y puede depender de otros cuadrados como este azul. Ahora, debido a esta dependencia, ya no podemos enfocar nuestras pruebas solo en el cubo naranja y debemos tener en cuenta de alguna manera el cubo azul. Aquí es donde podemos simular el cubo azul para sustituirlo por un cubo aparentemente compatible pero que será diferente. Y debido a esto, podemos controlar esta dependencia y conexión entre módulos y asegurarnos de que nuestra prueba del cubo naranja esté enfocada.

2. API Mocking: Server vs Client

Short description:

La simulación de API nos permite sustituir la comunicación de API, pero tiene algunas desventajas. El uso de un servidor de simulación requiere la obtención de dependencias y garantizar la operatividad del servidor. Las URL condicionales pueden llevar a desviaciones entre el entorno de prueba y producción, lo que puede causar problemas potenciales para los clientes.

Y la simulación de API es una técnica que nos permite sustituir la comunicación de API, es decir, las solicitudes HTTP, de la misma manera. Hay dos prácticas principales cuando se trata de implementar la simulación de API en tus proyectos.

La primera es utilizar un servidor de simulación. Esta es una configuración bastante sencilla y significa que tienes un servidor HTTP independiente que sustituirá a uno de producción. Aunque es bastante fácil de configurar y tiene algún tipo de sintaxis de abstracción para escribir las rutas y respuestas, creo que tiene algunas desventajas. Principalmente, sin importar lo que vayas a usar, ya sea que escribas tu propio servidor o uses una biblioteca de terceros, terminarás obteniendo dependencias y todo el proceso se sentirá como si estuvieras escribiendo un servidor real pero no lo estás haciendo. Luego debes asegurarte de la operatividad de tu servidor, para que se inicie y se detenga en el momento adecuado antes o después de tus pruebas, y luego no haya excepciones en tiempo de ejecución que puedan hacer que las pruebas fallen. Y lo peor de un servidor simulado son las URL condicionales. Y esto es a lo que me refiero con ellas. Este es un ejemplo abstracto de código donde tenemos una llamada fetch a una API backend.com. Ahora, no queremos acceder a esa URL de producción durante las testing, así que probablemente hemos introducido alguna variable de entorno que dice que, hey, si estás ejecutando pruebas, simplemente accede a esta otra URL en localhost porque aquí es donde tenemos el servidor simulado en ejecución. Ahora, el problema con esto es que durante la ejecución de las pruebas, el código nunca llegará a esta línea, que sí se ejecuta en producción. Y digamos que cometimos un error aquí. Escribimos mal un protocolo o nos faltaron algunas barras o puntos. Ahora, esto resultará en una prueba perfectamente exitosa en CI mientras que la aplicación se bloqueará por completo para nuestros clientes. Y la razón de esto es porque introdujimos una desviación. Por lo tanto, la aplicación que se ejecuta durante las pruebas es ligeramente diferente a la que se ejecuta en las máquinas de los clientes. Y cuanto más alteres el sistema bajo prueba, más estás probando un sistema completamente diferente.

3. API Mocking: Enfoque de Simulación de Cliente

Short description:

El otro enfoque para la simulación de API es utilizar un cliente simulado. Sin embargo, este enfoque presenta varios problemas. Los clientes simulados requieren una cuidadosa consideración de la validez de las solicitudes y respuestas, una estrecha dependencia con las bibliotecas y el hecho de que la lógica real nunca se ejecuta. Un enfoque mejor es llamar al cliente de solicitud real y permitir que la solicitud salga de la aplicación, mientras se recibe una respuesta simulada para controlar diferentes escenarios del servidor.

Creo que el otro enfoque para la simulación de API es utilizar un cliente simulado. Aquí tienes un ejemplo rápido de cómo espiar en window.fetch y decir que cada llamada a fetch debería resolver en este JSON que hemos especificado. Lo que esto va a hacer es que en lugar de llamar a la función fetch real en el navegador o durante la prueba, siempre llamará a esta simulación y devolverá este JSON fijo.

Ahora probablemente no queremos que todas las solicitudes devuelvan el mismo JSON. Así que queremos introducir alguna lógica donde las respuestas dependan de las solicitudes. Y terminamos escribiendo esta simulación del cliente de la API, que tiene esta lógica. Y luego nos damos cuenta de que también necesitamos tener en cuenta algunos comportamientos comerciales y también tener en cuenta los encabezados y otras cosas para que esta simulación del cliente de la API se sienta realista. Y al final, terminamos con una gran obstrucción, que escribimos solo por el bien de las pruebas.

También hay un par de problemas más con los clientes simulados. Por ejemplo, debido a que estamos sacando el cliente y reemplazándolo, debemos asegurarnos de que las solicitudes y respuestas tengan sentido, que cumplan con las especificaciones, y que sean similares o idénticas a lo que sucederá en la aplicación real. La entrada a dicho cliente simulado siempre se considera válida. Así que a menos que de alguna manera validemos las solicitudes y respuestas, el cliente simulado las procesará y las ejecutará, incluso si tienen un error tipográfico, por ejemplo. Luego, los clientes son bastante diferentes, y la forma en que se manejan las respuestas y solicitudes en Fetch puede ser diferente para XHR y Apollo. Así que también debemos tener eso en cuenta al escribirlo. Y esto crea una dependencia muy estrecha entre nuestra simulación y las bibliotecas reales que usamos, lo que dificulta mucho la migración y ver cómo evoluciona nuestro software.

Lo peor es que las solicitudes nunca ocurren con el cliente simulado. Eso es más o menos lo que escribimos, ¿verdad? En lugar de llamar a Fetch o Apollo reales, llamamos a su contraparte simulada. Por lo tanto, la lógica real nunca se ejecuta. Tengamos eso en cuenta y pensemos en cuál podría ser un enfoque mejor.

Aquí tenemos una aplicación. Puede ser una aplicación real que se ejecuta en el navegador o simplemente una parte de una aplicación en la prueba de integración. El punto es que esta aplicación realiza una solicitud. Ahora, queremos que esta solicitud ocurra. Queremos que se llame al cliente de solicitud real y que la solicitud salga de la aplicación. ¿Por qué? Porque esto es lo que sucede en producción. Y si nos mantenemos cerca de esto, obtendremos más confianza en nuestras pruebas. Pero no queremos que esta solicitud llegue a un servidor real. De esa manera, si el servidor está caído o funciona incorrectamente, nuestra prueba fallará. Pero el objetivo de nuestra prueba del lado del cliente es probar el cliente, ¿verdad? No el servidor. Pero aún queremos recibir una respuesta simulada para poder controlar diferentes escenarios del servidor por prueba y que se reproduzcan de manera confiable.

4. Usando Service Workers para Simulación

Short description:

Podemos elegir ni un cliente simulado ni un servidor y en su lugar utilizar un service worker. Los service workers son módulos de JavaScript que residen junto a tu aplicación en un navegador y se ejecutan en un hilo separado. Pueden interceptar solicitudes y responder con respuestas en caché o simuladas. Sin embargo, utilizar service workers para simulación presenta desafíos como un contexto de ejecución limitado, posibles workers desactualizados y confusión al controlar clientes no relacionados. Para abordar estos desafíos, creé la biblioteca MockServiceWorker (MSW), que aprovecha los service workers para interceptar solicitudes y proporcionar respuestas simuladas.

Siempre tendemos a elegir entre un cliente simulado o un servidor. Pero en realidad, hay algo intermedio, y eso se llama service worker. Un service worker es una API que es una especie de web worker, un módulo de JavaScript que reside junto a tu aplicación en un navegador y se ejecuta en un hilo separado.

Este es un ejemplo de un archivo de worker. Los workers tienen ciertos eventos del ciclo de vida y uno de ellos es el evento de fetch. El worker lo activa cada vez que tu aplicación realiza cualquier tipo de solicitud. En este controlador, indico que quiero buscar la respuesta en caché y, si hay una respuesta en caché, simplemente responda con ella, sin realizar solicitudes reales. Pero si no hay caché, ejecute la solicitud fetch como de costumbre.

Ahora puedes ver cómo, con esto, hay un gran potencial para implementar el almacenamiento en caché de esta manera en el lado del cliente, pero esto me hizo pensar, ¿qué pasaría si en lugar de respuestas en caché, pudiéramos devolver respuestas simuladas? Intentemos eso. El mismo worker, pero esta vez en el evento de fetch, respondemos con este cuerpo de respuesta codificado y el código de estado 200. Y ahora, cualquier solicitud que realice nuestra aplicación, saldrá de la aplicación y llegará al worker, y como respuesta, se devolverá esta respuesta estática.

Esto es genial, así que usemos Service Workers para simulación y el problema estará resuelto. Pero si intentas hacer eso, te enfrentarás a varios desafíos. En primer lugar, los Service Workers tienen un contexto de ejecución limitado, y esto se debe principalmente a consideraciones de seguridad. No puedes acceder al objeto window o al DOM y, obviamente, no puedes acceder al código del lado del cliente ni a tus funciones, utilidades y bibliotecas. Los workers pueden quedar obsoletos y cada vez que registras un worker, esto no necesariamente empuja el último worker al navegador y puedes terminar con un worker obsoleto, lo cual no es agradable. Cuando cargas la página, el worker se detendrá y tendrás que volver a cargar la página para verlo en funcionamiento nuevamente. Esto crea una experiencia de desarrollo distorsionada. Los workers también controlan clientes no relacionados y lo hacen porque el worker establece una conexión con el cliente en función de su URL. Por lo tanto, puedes abrir un proyecto completamente diferente en la misma URL, en localhost, y ver un worker no relacionado que intenta simular respuestas. Y esto es simplemente confuso.

A pesar de estos desafíos, me gusta la idea. Hace un par de años, escribí la biblioteca llamada MockServiceWorker o MSW abreviado. Y aprovecha la capacidad de ServiceWorker para interceptar solicitudes y hacerlo de manera elegante. MSW es lo más parecido a un servidor real sin tener que crear uno, y esto es gracias a los Service Workers. Permíteme mostrarte cómo se ve el flujo de trabajo con la biblioteca antes de adentrarnos en los detalles internos. Lo primero que haré es indicarle a la biblioteca qué solicitudes capturaré. Y estoy escribiendo estas cosas llamadas controladores de solicitud, simplemente funciones que describen la información de la solicitud y qué respuesta producir.

5. Usando MSW para Simulación de API

Short description:

Aquí estoy apuntando a una solicitud de API REST al endpoint de usuario y generando una respuesta simulada con el nombre John. El worker intercepta las solicitudes realizadas por la aplicación, las clona y las envía de vuelta a MSW. MSW encuentra el controlador para la solicitud y devuelve la respuesta simulada al worker, que responde a la solicitud original en el cliente. Con MSW y los service workers, no hay solicitudes fantasma ni URLs condicionales. MSW se puede utilizar para pruebas, desarrollo, depuración y prototipado.

Aquí estoy apuntando a una solicitud de API REST, que es una solicitud GET al endpoint de usuario. Y estoy generando esta respuesta simulada, este cuerpo JSON con el nombre John. Una vez que termino con los controladores y describo todo el comportamiento del servidor, creo un worker llamando a setup worker y proporcionando mis controladores. Y luego inicio este worker, que se registrará y activará en el navegador.

Importo este módulo en mi aplicación, y puedo ver que ahora, cuando hago una solicitud a /usuario, se intercepta y recibo la respuesta simulada. Pero, ¿cómo funciona exactamente? Entonces, cada vez que la aplicación realiza una solicitud, es interceptada por el worker. El worker clona la solicitud y la envía de vuelta a MSW porque MSW no se ejecuta en el worker En cambio, se ejecuta junto a tu código de cliente. Por lo tanto, puedes usar tus lenguajes, bibliotecas y utilidades favoritas allí. MSW intenta encontrar el controlador para esta solicitud. Cuando lo encuentra, devuelve la respuesta simulada al worker y el worker la utiliza para responder a la solicitud original en el cliente.

Ahora, con MSW y gracias a los service workers, ya no hay más solicitudes fantasma, solicitudes que nunca ocurrieron. En su lugar, puedes ver claramente las solicitudes en la pestaña de red porque realmente ocurren, igual que en producción. Ya no hay más pestaña de solicitudes de clientes. No intervenimos con fetch u otras bibliotecas y debido a eso, obtenemos una completa conformidad con las especificaciones. Porque se llama al cliente de solicitud y la respuesta se compone en el sitio del service worker. Si alguna de estas partes es inválida, se lanzará una excepción. Y lo siento, ya no hay más URLs condicionales, lo cual, nuevamente, es gracias al service worker y podemos obtener un comportamiento de aplicación idéntico al de nuestra aplicación en producción.

Entonces, ¿cuándo usarías MSW? Bueno, en primer lugar, puedes usarlo para testing. Una vez que hayas escrito los controladores de solicitud, puedes reutilizarlos para pruebas de integración y también para pruebas de extremo a extremo con Cypress o Puppeteer. Puedes llevar este concepto aún más lejos y usar MSW para desarrollo. Digamos que tu backend no está listo o sufre un cambio o quieres experimentar con alguna API de terceros. Puedes probarlo primero con MSW. El siguiente caso es la depuración, y es mi favorito. Porque cuando hay un problema relacionado con los data, puedes crear un controlador para una solicitud específica e intentar encontrar qué respuesta provoca el fallo en tu aplicación. Una vez que lo encuentres, tendrás una forma confiable de reproducir el problema y, por lo tanto, solucionarlo. También puedes usar MSW para prototipado. Cuando estás construyendo tu próximo producto increíble, y el backend puede que no esté listo, pero aún puedes escribir código del lado del cliente y puedes usar MSW para actuar como un backend. Así que aquí podemos probar una API RESTful. Y tal vez mañana queramos echar un vistazo a cómo se sentiría nuestra aplicación con GraphQL. Simplemente usamos un controlador de solicitud de GraphQL, y no tenemos que comprometernos con todo el ecosistema de GraphQL solo para probarlo.

6. Características y Conclusión

Short description:

MSW ofrece muchas características. Está escrito en TypeScript y es compatible con cualquier cliente que emita solicitudes. Puedes usarlo con cualquier cliente y con Node.js. Empresas como Google, Spotify y Gatsby ya están utilizando MSW. Consulta el repositorio y la documentación para obtener más información. También hay un video en YouTube y el curso Epic React que presenta MSW. Sigue a API Mocking en Twitter para recibir actualizaciones y no dudes en conectarte conmigo. Gracias.

MSW ofrece muchas más características. Por ejemplo, está escrito en TypeScript, por lo que puedes usar definiciones de tipos para anotar tus solicitudes y respuestas y asegurarte de estar seguro. Es compatible con cualquier cliente que emita solicitudes, ya sea Native Fetch, React Query o Apollo. No hay lógica específica de la biblioteca.

También puedes usar MSW con Node.js, para ejecutarlo en Jest o cuando desarrollas en servidores Node.js para simular comunicación de terceros. Empresas como Google, Spotify y Gatsby ya están utilizando MSW. Y estás a un comando de distancia de probarlo tú mismo, así que no te lo pierdas. Asegúrate de consultar el repositorio en msw.js.msw y también la documentación en msw.js.io donde puedes leer más sobre la biblioteca, su API, ver algunos ejemplos de uso, y también compararla con otras herramientas de simulación de API disponibles.

Si eres un aprendiz más práctico, definitivamente mira ese video de YouTube para simular una respuesta HTTP básica que va desde el inicio hasta el final, configurando MSW y preparando las simulaciones en menos de cuatro minutos. Y no te pierdas el curso Epic React de Kansi Dots, que es una gran colección de material sobre cómo construir aplicaciones React increíbles. Y presenta MSW en su sección de testing.

Asegúrate de seguir a API Mocking en Twitter para estar al tanto de las actualizaciones de la biblioteca, y también puedes seguirme para saludar o hacer una pregunta. Siempre estoy feliz. Espero que esta charla te haya sido útil y ahora puedas escribir pruebas con más confianza y tal vez MSW pueda contribuir a eso. Gracias.

QnA

Actualizaciones sobre MSW y Preguntas y Respuestas

Short description:

Estamos trabajando en una mejor integración de GraphQL y buscando soporte para WebSockets. También estamos explorando diferentes enfoques en desarrollo y pruebas, incluyendo un enfoque basado en datos. La comunidad está creciendo rápidamente. En cuanto a la integración de MSW con PECT, no lo he probado, pero debería ser posible. En cuanto a las diferencias entre Cypress MOC y MSW, la principal distinción es que MSW utiliza service workers para interceptar las solicitudes a nivel de red. Aunque algunas personas lo utilizan en producción, principalmente es con fines educativos.

Tal vez en el ínterin te gustaría contarnos algo sobre lo que está sucediendo con MSW? No, lo siento, MSW, ese es el orden correcto. ¿Escuché que hay algunas cosas interesantes en marcha? Sí, definitivamente. Tenemos a algunas personas que se unen al equipo y con más personas que lo usan y contribuyen, recibimos muchas solicitudes. Y ahora estamos trabajando en una mejor integración de GraphQL para poder admitir suscripciones. Y también estamos buscando soporte para WebSockets porque, bueno, nosotros usamos WebSockets, pero no hay muchas soluciones que admitan la simulación de eso.

Sí. Y también estamos tratando de admitir más enfoques en desarrollo y testing. Por ejemplo, sé que a la gente le gusta un enfoque basado en datos para que puedan definir el esquema y luego generar diferentes entidades y tener las simulaciones basadas en eso. Así que también estamos trabajando en una solución de modelado de datos para ayudar en eso.

Eso suena increíble. La comunidad está creciendo realmente. Sí, es increíble. Estoy listo para eso. De acuerdo, genial. Veo que hay algunas preguntas llegando. Stephen quiere saber, ¿puedes integrar MSW y PECT? ¿Tienes alguna información al respecto? No lo he probado, pero no veo por qué no sería posible. Así que supongo que es una buena oportunidad para probarlo y hacérnoslo saber. De acuerdo, genial. Entonces, Stephen, si lo pruebas, por favor háznoslo saber cuál es la respuesta. Stephen quiere saber, ¿puedes enumerar algunas diferencias entre la función MOC de Cypress y MSW? Supongo que con MOC de Cypress, se refieren a Cypress Intercept, tal vez. No he oído hablar de la API MOC. Pero en cualquier caso, creo que en Cypress, la intercepción de solicitudes se hace a través del stubbing de fetch o XHR, por lo que esa sería la principal diferencia. Porque cuando usas service workers, no tienes que hacer eso, como mencioné en la charla. En realidad permites que tu aplicación realice las solicitudes. Y todo sucede, todo el código del cliente de la solicitud se llama, y luego el service worker lo intercepta a nivel de red. Así que supongo que esa sería la principal diferencia. Pero también puedes usar MSW con Cypress y tenerlo funcionando junto con tu aplicación en Cypress y luego que maneje la simulación. De acuerdo, genial. Creo que eso también responde a la siguiente pregunta. Vatilis quiere saber, ¿usarías MSW en producción como una especie de API gateway? Bueno, hay algunas personas que usan MSW en producción, pero principalmente es con fines educativos.

Ejecutando MSW en Producción

Short description:

Poner el worker en la máquina del usuario y mantenerlo sincronizado puede ser un desafío. Los service workers están principalmente destinados a producción, pero es posible ejecutar MSW en producción. Sin embargo, se utiliza más comúnmente para propósitos de prueba y desarrollo.

No creo que sea una buena idea, porque una vez que pusieras el worker en la máquina del usuario, serías responsable de mantenerlo sincronizado. Y como mencioné, los workers son bastante complicados, e incluso si registras la nueva versión, no significa que la antigua se reemplace inmediatamente. Y si no quieres quedarte atrapado en esta lógica de MOCs obsoletos, probablemente no lo recomendaría. Pero definitivamente puedes intentarlo. Quiero decir, los service workers están destinados a producción. Y si encuentras valor en eso, en ejecutar MSW en producción, tal vez, sí, inténtalo. Así que es posible, pero la depuración es quizás un caso de uso más común. Sí. Se enfoca principalmente en testing y desarrollo en lugar de actuar como una puerta de enlace.

WSMOCs y Mocking RPs

Short description:

Richard preguntó sobre WSMOCs y su introducción y soporte para respuestas dinámicas. El orador explica los casos de uso para el mocking de RPs, incluyendo el mocking de RPs de terceros y decidir si se deben mockear RPs propios basado en el nivel de prueba. El orador aclara que Richard se refería a los mocks de web sockets y menciona que están trabajando en el soporte para WebSockets. El orador anima a los usuarios a probarlo y proporcionar comentarios. En cuanto a las respuestas dinámicas, el orador sugiere plantear la preocupación en GitHub.

De acuerdo. Richard dice, hola, estaba a punto de preguntar sobre WSMOCs. ¿Cuándo es probable que se introduzca? ¿Soportará respuestas dinámicas? No estoy seguro de entender WSMOCs. Eso es lo que estaba escrito. Tal vez Richard pueda aclarar eso.

Mientras tanto, vamos a la pregunta de Testibyte. ¿Cuáles son algunos de los casos de uso para el mocking de RPs? Mockear RPs de terceros tiene sentido casi siempre. ¿Mockearías RPs propios? Supongo que depende del nivel de prueba en el que te encuentres. Porque si estás probando tus componentes, como la integración de ellos, como por ejemplo un formulario de inicio de sesión o un formulario de pago, solo un pequeño fragmento de código que escribiste, pero que ya tiene múltiples componentes y tal vez hace solicitudes. Supongo que tiene sentido mockear tu propia API aquí porque no quieres depender de un servidor real durante esta prueba. Y una vez que lo llevas a un nivel más alto, a pruebas de extremo a extremo, probablemente aquí quieras acceder a tus puntos finales reales y asegurarte de que funcione para los clientes. Probablemente lo dividiría así. Sí. Y probablemente depende del tamaño de tu proyecto y del nivel de pruebas que estés realizando.

De acuerdo. ¿Hemos recibido alguna respuesta de Richard para poder responder la pregunta? Oh, mocks de web sockets. Lo siento, se refería a mocks de web sockets. De acuerdo, entendido. ¿Quieres que repita toda la pregunta? Sí, si no te importa. Hola, estaba a punto de preguntar sobre mocks de web sockets. ¿Cuándo es probable que se introduzca? ¿Soportará respuestas dinámicas? De acuerdo, como mencioné, también estamos trabajando en el soporte para WebSockets. Inicié el prototipo hace unos meses, pero supongo que aún necesita algunos ajustes y esperaría que esté disponible en algún momento de este año, pero probablemente más cerca del verano. Depende de las prioridades, pero definitivamente sería bueno tenerlo allí para que las personas puedan probarlo y hacernos saber, porque obviamente no podemos predecir todos los casos de uso que tienen. Así que una vez que esté disponible, pruébalo y háznoslo saber. En cuanto a las respuestas dinámicas, en realidad no estoy seguro. No tengo mucha experiencia con WebSockets yo mismo, como usarlos. Estoy investigando cómo se implementaron y la especificación, pero aún no he llegado a la parte de esta función. Así que si te preocupa esto, te sugiero que vayas a GitHub y lo plantees en la solicitud de extracción.

Mejoras próximas en la experiencia del desarrollador

Short description:

Tenemos algunas pequeñas mejoras en la experiencia del desarrollador que llegarán la próxima semana. Ayudaremos a los usuarios a depurar escenarios cuando las solicitudes no sean interceptadas utilizando lógica de coincidencia de cadenas para sugerir el controlador previsto.

Así que no nos lo perderemos. Gracias. Bueno, pero el verano no está tan lejos. ¿Podemos probarlo pronto? Haremos nuestro mejor esfuerzo. ¿Tienen algún plan para la próxima versión? Quiero decir, ya hablamos un poco sobre el resto de la hoja de ruta. Sí, tenemos algunas pequeñas mejoras en la experiencia del desarrollador, que creo que se lanzarán la próxima semana. Muchas personas estaban pidiendo ayuda para depurar escenarios cuando las solicitudes no son interceptadas. Y esto es muy común. A veces hay un error tipográfico, a veces hay un nombre de dominio incorrecto o algo así. Y ya tenemos cierta lógica básica que simplemente te dirá, oye, esto no está interceptado, pero vamos a llevarlo más lejos y vamos a utilizar lógica de coincidencia de cadenas que te sugerirá el controlador que quizás quisiste decir. Así que cada vez que solicites el recurso, vamos a verificar, oye, tal vez hiciste un error tipográfico, o tal vez solicitaste una consulta GRFQL, pero quisiste decir imitación con el mismo nombre. Así que espera eso, creo que la próxima semana. Esa es una característica genial y útil. Así que la próxima semana podría ser el momento perfecto para probar este framework si aún no lo has hecho. Así que definitivamente tengo que ponerlo en mi lista. Y Tiger quiere saber, ¿los WebSockets permitirán suscripciones GRFQL con MSW? Sí, sí, definitivamente. Espero que sí. La última vez que lo comprobé, funcionaban a través de WebSockets. Así que una vez que tengamos los WebSockets implementados primero, podemos ver las suscripciones GRFQL y si necesitamos hacer algún trabajo adicional allí. OK, genial. Y escucho a la gente realmente emocionada por esa característica. Así que eso también llegará la próxima semana, ¿no? ¿Te refieres a qué, WebSockets? Sí. Eso ya es parte del framework. Oh, no, no, no, me refería que sucederá cerca del verano. Ah, necesitarán algo de trabajo. OK, genial. No tenemos más preguntas en este momento. Así que si hay algo más. Sí, gracias por las preguntas. Ha sido realmente genial. Fue genial tenerte aquí y nos vemos en la sala de los oradores, por favor, si hay alguien más con quien quieras hablar con Artem, únete al chat especial. Y muchas gracias. Sí, gracias por tenerme. Ha sido un placer. Gracias, adiós.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
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
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
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
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Ú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.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.