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

♪♪ 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.

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.

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.

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.

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.

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.

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.

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.

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.