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

Rate this content
Bookmark

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.

25 min
15 Jun, 2021

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

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

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.