Mock Service Worker 2.0

Rate this content
Bookmark

Ha pasado medio decenio desde que Mock Service Worker (MSW) cambió la forma en que los desarrolladores abordan y piensan en la simulación de API en JavaScript. Con toda su innovación, sentí que podríamos hacer más. Pasé el último año haciendo que eso sucediera. ¡No puedo esperar para compartirlo con todos ustedes!

Artem Zakharchenko
Artem Zakharchenko
27 min
07 Dec, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

MSW es una biblioteca de simulación de API que simplifica el proceso de interceptar solicitudes y simular respuestas. Aprovecha las API estándar de JavaScript como la API de ServiceWorker y la API de Fetch. MSW ha visto una adopción significativa, con más de 90,000 proyectos en GitHub y 2.5 millones de descargas semanales en npm. El reciente lanzamiento de Node.js 18 ha permitido la refactorización y simplificación en MSW. MSW admite TypeScript y se puede utilizar para pruebas de contrato con herramientas como PACT I-O.

Available in English

1. Introducción al mocking de API con MSW

Short description:

Hola a todos. Hoy, me gustaría hablar sobre el mocking de API, los estándares, JavaScript y MockServiceWorker. MSW es una biblioteca de mocking de API que te permite interceptar solicitudes y simular respuestas. Introduce el mocking de API como una capa independiente, resolviendo el problema de las descripciones de red repetitivas en diferentes herramientas. MSW logra el mocking de API sin recurrir a parches de window.fetch, confiando en su lugar en la API estándar de JavaScript como la API de ServiceWorker.

Hola a todos. Es un placer estar aquí y gracias por unirse. Hoy, me gustaría hablar sobre el mocking de API, standards, JavaScript y, por supuesto, MockServiceWorker.

Primero lo primero. Mi nombre es Artem. Puedes encontrarme como Ketanaito prácticamente en todas partes, incluyendo mi humilde blog en ketanaito.com. Y también puedes conocerme como el autor de MockServiceWorker.

Por curiosidad, ¿puedes levantar la mano si has oído hablar de MSW? Vaya, eso es mucho. Disfrutarás de esta charla. Sí, así que para aquellos que no han oído hablar de él, MSW es una biblioteca de mocking de API. Así que en esencia, te permite interceptar solicitudes y simular respuestas, básicamente controlar tu red para lo que quieras, testing, prototipado, depuración.

Y tiene un enfoque un poco único para el mocking de API. Introduce el mocking de API como una capa independiente. Así que si piensas en cómo controlas tu red durante testing, por ejemplo, bueno, tienes un montón de estas diferentes herramientas, ¿verdad? Tienes herramientas como Playwright y Cypress y Vitesse y Jest, y todas vienen con sus propias capacidades de mocking de API, que son increíbles. Pero lo que pasa es que, una vez que logras esta cobertura total de pruebas de tu producto, empiezas a notar que estas descripciones de red que haces, se repiten. En esencia, sólo quieres hacer una cosa, describir la red, pero estás usando diferentes APIs de diferentes frameworks, y no saben el uno del otro. No pueden comunicarse. Hay muy poco que puedas reutilizar. Y eso es precisamente lo que resuelve MSW. Eleva esta intención. Así que tienes una sola capa de descripción de tu red, y luego la integras en una herramienta en particular. Y como guinda del pastel, logra el mocking de API sin recurrir a estos desagradables parches de window.fetch y en su lugar confía en la API estándar de JavaScript, como la API de ServiceWorker, si estamos hablando de la interceptación del lado del navegador.

Pero, ¿cómo haces eso? ¿Cómo describes la red con MSW? Bueno, usas estas funciones llamadas manejadores de solicitudes. Te mostraré un ejemplo. Así que este es un manejador de solicitudes muy simple. Puedes ver que la intención aquí es interceptar una solicitud POST al endpoint de slash user. Y luego tenemos esta función de callback que debería producir la respuesta. Tenemos solicitud, argumento, respuesta y contexto. Así que lo que vamos a hacer con esta solicitud, intentaremos leer su cuerpo como JSON. Así que MSW intentará ser inteligente aquí, de hecho, y ver qué encabezado de tipo de contenido tiene tu solicitud.

2. Mocking de API y Mejoras en JavaScript

Short description:

Si es application slash JSON, intentará analizarlo y devolverte el objeto. Usamos esta función de composición REST para componer un montón de utilidades de contexto, como este context.json para devolver una respuesta JSON. MSW celebra su quinto aniversario este año. JavaScript ha recibido muchas mejoras a lo largo de los años. Frameworks como Next.js y Remix están abandonando las abstracciones personalizadas y apostando más por JavaScript. MSW tiene más de 90,000 proyectos en GitHub y más de 2.5 millones de descargas en npm cada semana.

Y si es application slash JSON, intentará analizarlo y devolverte el objeto. Así que estamos accediendo a la propiedad name aquí. Y luego para devolver una respuesta simulada, usamos esta función de composición REST para componer un montón de utilidades de contexto, como este context.json para devolver una respuesta JSON. Así que este es un ejemplo muy, muy básico de tu descripción de red.

Y una cosa que me gusta hacer cuando uso cualquier biblioteca de terceros, me gusta hacer este divertido ejercicio. Así que tomo un ejemplo muy básico como este, y elimino todo lo que no es estándar JavaScript. Así que hagamos justamente eso. Oh, no queda realmente mucho. Básicamente todo lo que estaba escrito allí sigue siendo válido y funcional, pero son todas abstracciones. Si lo piensas, REST.POST es una abstracción. Es algo específico de la biblioteca. Lo mismo que esta firma de llamada de los resolutores de respuesta. En ninguna otra parte de JavaScript usas esta firma de llamada para manejar solicitudes. La función de respuesta, por mucho que me guste la composición funcional, no es tan común en JavaScript, para bien o para mal. Y, por supuesto, las utilidades de contexto, una API completamente inventada. Y esta API ha sido funcional y ha estado trabajando durante años.

De hecho, este año, creo, MSW celebra su quinto aniversario. Y puedes decir, bueno, si no está roto, simplemente no lo arregles. No soy un gran fan de eso. De hecho, trabajar en código abierto, creo, me ha enseñado un motivo mucho más importante. Si no es educativo, no lo envíes. Porque mi objetivo como mantenedor de código abierto es compartir mis ideas. Pero también quiero que todos esos desarrolladores que les gustan mis ideas y usan mis ideas mejoren en JavaScript, en el lenguaje, no en mis pequeños proyectos. Porque, si lo piensas, JavaScript ha recibido muchas mejoras a lo largo de los años. Y puedes ver esto muy aparentemente en las direcciones que los frameworks como Next.js y Remix están tomando. Están abandonando esas abstracciones personalizadas. Y están apostando cada vez más por JavaScript porque es increíble. Resulta que MSW ha sido muy utilizado. Tiene más de 90,000 proyectos en GitHub usando MSW. Y más de 2.5 millones de descargas en npm cada semana.

3. Motivación para Mejorar MSW

Short description:

Hay una cantidad increíble de desarrolladores que tienen que aprender funciones personalizadas para MSW que quizás nunca vuelvan a usar. JavaScript está en todas partes en nuestra era moderna, incluso en aplicaciones cotidianas como Messenger. Decidí mejorar MSW para enseñar a las personas a ser mejores en JavaScript.

Esa es una cantidad increíble de desarrolladores que tienen que revisar la documentación, aprender sobre estas funciones personalizadas que nunca antes habían escuchado y probablemente nunca volverán a usar aparte de MSW. Eso es simplemente mucho. Y recientemente me di cuenta, vivimos en la era moderna donde JavaScript está en todas partes a nuestro alrededor. Estaba reservando entradas para esta masterclass e interactué con JavaScript. Llamé a mi madre la noche anterior y la aplicación Messenger tiene partes en JavaScript. Entonces, si resulta que tengo una pequeña influencia sobre las personas que escriben ese JavaScript, ¿por qué no les enseño a ser mejores en ello? Y eso es precisamente lo que intenté hacer hace aproximadamente un año. Así que me embarqué en esta misión, necesitamos mejorar MSW.

4. Desafíos con Solicitudes y Respuestas Isomórficas

Short description:

Por mucho que sea increíble, puede ser mejor. Deberías simular tu red de la misma manera que la usas en producción. En el navegador, puedes usar Fetch API o XMLHttpRequest. En Node.js, hay más formas de hacer solicitudes de las que hay estrellas en el cielo. MSW intenta llevar todas estas diferentes formas al común denominador con solicitudes y respuestas isomórficas. Sin embargo, resultó ser bastante complicado, ya que los desarrolladores quieren manejar varias características al trabajar con la red.

Por mucho que sea increíble, puede ser mejor. Así que la perspectiva principal fue uno de los puntos clave que tuvimos en la biblioteca desde el principio. Deberías simular tu red de la misma manera que la usas en producción, por ejemplo. Así que veamos cómo haces eso.

En el navegador, lo más probable es que estés utilizando Fetch API o una abstracción de Fetch API, es una API fantástica. O tal vez estés utilizando XMLHttpRequest, que sigue siendo genial para ciertas situaciones, aunque sea un poco más antiguo. Y en Node.js, es un poco más enredado. La principal forma de hacer solicitudes en Node.js es el módulo HTTP, que probablemente no estés usando directamente por una buena razón. Así que normalmente dependes de bibliotecas de terceros para hacer solicitudes, para manejar respuestas. Y una cosa particular que aprendí al escribir una intercepción de solicitudes para Node.js es que hay más formas de hacer solicitudes en Node que estrellas en el cielo. Y desafortunadamente, eso es cierto, especialmente cuando te sumerges en el terreno del usuario y lo que las personas están construyendo sus propias bibliotecas y usan Node.js de todas las formas posibles, a veces de acuerdo con las especificaciones, a veces no. Pero lo que intentamos hacer en MSW es tomar todas estas diferentes formas en que puedes definir solicitudes y respuestas y llevarlas al común denominador. E introdujimos este concepto de solicitudes y respuestas isomórficas. Básicamente, de nuevo, una abstracción para manejar todas estas diferencias. Pero resultó ser bastante complicado. Porque sí, puedes representar solicitudes y respuestas muy básicas, pero hay muchas características que los desarrolladores quieren al trabajar con la red. Quieres poder manejar buffers de array, archivos, formularios data, cargas, streaming, tal vez abortar la solicitud. Y tuvimos que implementarlo nosotros mismos. Así que no importa cómo declares las solicitudes, todavía obtienes esas capacidades. Fue un gran lío.

5. Lanzamiento de Node.js 18 y Refactorización

Short description:

Node.js 18 fue lanzado, introduciendo la API fetch como un terreno común para representar la red tanto en el navegador como en Node.js. Esto permitió una refactorización y simplificación, eliminando código y documentación innecesarios.

Y justo cuando estaba perdiendo la fe en toda la humanidad, ocurrió algo increíble. Node.js 18 fue lanzado. Ahora, este fue un gran lanzamiento, especialmente para mí, porque estaba profundamente involucrado en la refactorización en MSW y todavía prometíamos soporte para Node.js 14 y 16. Así que realmente no había un terreno común para representar la red hasta que esto sucedió. Y por supuesto, estoy hablando de una de las características más grandes de este lanzamiento. Fue la API fetch, esta misma función fetch con la que todos están familiarizados, estoy bastante seguro. Pero no es solo esa función. Se han añadido muchas otras cosas, como streams legibles, headers, trabajando con señales de aborto y URL. Y si esas cosas no fueron introducidas directamente por este lanzamiento, fueron facilitadas. Fueron mucho más fáciles de usar a través de la API fetch. Así que esto fue increíble. Estaba muy contento y pensé, hey, podemos usar la API fetch como el terreno común para ambos navegador y Node.js para representar la red. Y comencé a refactorizar y a emplear una de mis prácticas favoritas, tirar código. Y ha sido fantástico, sinceramente, solo tirar todas las sustracciones y toda la documentación porque ya no los necesitas.

6. MSW 2.0: Manejo de Solicitudes y Beneficios de JavaScript

Short description:

Y luego, un año después, llegamos a MSW 2.0. Es el mismo manejador de solicitudes, solo que con una nueva API. Trabajamos con el objeto de solicitud, llamamos a request.json y esperamos la promesa. Definimos una respuesta JSON utilizando el método JSON estático en la respuesta. El corazón del manejador de solicitudes, la lógica de simulación, es todo JavaScript estándar. Al utilizar la plataforma, los desarrolladores tienen una curva de aprendizaje poco profunda y pueden aprovechar las características de JavaScript de forma gratuita.

Y luego, un año después, llegamos a MSW 2.0. A simple vista, es prácticamente el mismo manejador de solicitudes. Este es, por cierto, el mismo manejador de solicitudes, solo que con una nueva API. Así que todavía tenemos la intención de interceptar la solicitud post al punto final del usuario. Pero en el callback ahora, simplemente obtenemos este objeto de solicitud. Y te puedes estar preguntando, ¿qué tipo de abstracción es esa?

Entonces, si observas cómo trabajamos con ese objeto de solicitud, puedes ver algo familiar. Es solo que estamos llamando a request.json y estamos esperando esa promesa. Parece un poco la API fetch porque lo es. Es solo una instancia de solicitud regular. Así que lo leemos como JSON y obtenemos una propiedad de nombre. Y si queremos definir una respuesta JSON, simplemente usamos el método JSON estático en la respuesta. De nuevo, la API de respuesta estándar en JavaScript y devuelve un objeto particular. Así que tomemos este ejemplo y hagamos el mismo ejercicio. Descartando todo lo que no sea JavaScript.

Boom. Claro, la forma en que declaramos el contrato de cómo interceptamos las solicitudes, será forzado hasta cierto punto. JavaScript, para ser franco, no tiene que lidiar con eso. Es bastante específico. Pero si echamos un vistazo a este corazón de este manejador de solicitudes, a esta lógica de simulación, es todo simplemente JavaScript estándar. Y eso es lo que importa. Porque cuanto más lógica escribas aquí, más JavaScript regular estarás usando. Y se hizo evidente muy rápido que al usar la plataforma, todos ganan. Y estoy hablando de desarrolladores y también estoy hablando de mantenedores, como yo. Los desarrolladores, bueno, para empezar, tienen una curva de aprendizaje poco profunda. Simplemente no tienes que perder tu tiempo en los documentos leyendo sobre todas estas abstracciones elegantes que los autores de la biblioteca crearon. Puedes simplemente usar JavaScript. Obtienes características de forma gratuita. Como si quieres simular, no sé, un stream legible, simplemente puedes hacerlo. Porque eso es lo que permite la API Fetch. No hay necesidad de que MSW lo implemente explícitamente.

7. Beneficios de MSW y Soporte

Short description:

Puedes aplicar los conocimientos adquiridos al usar MSW a otras áreas de desarrollo. Los mantenedores de código abierto cometen errores y mejoran constantemente. Prueba MSW instalándolo con npm. Profundiza con el curso de Mock REST y APIs GraphQL. Apoya el proyecto económicamente o a través de contribuciones.

Y por supuesto, simplemente te vuelves mejor en el lenguaje. Como mencioné antes. Entonces, interactúas con estas primitivas más a menudo. Te familiarizas más. Y este conocimiento que adquieres al usar MSW, puedes aplicarlo incluso fuera cuando yo no sé, escribiendo cargadores en Remix o manejando solicitudes en Next. Todos ellos dependen de la misma API Fetch.

Y los mantenedores, por supuesto, podemos enviar menos código. Y es genial porque significa menos código para mantener y menos errores. Obtenemos una mejor compatibilidad. Porque si todo en el ecosistema un día se basa en el mismo terreno común, esto significa que las personas, nuestros usuarios, pueden simplemente usar la misma lógica, las mismas funciones de utilidad, las mismas pruebas, en todas partes a lo largo de la pila porque es la misma dependencia en JavaScript.

Y a pesar de la creencia común, los mantenedores de código abierto no son estas criaturas sabias y omniscientes. Cometemos errores y tenemos que iterar y mejorar mucho. Y cuanto más interactuamos nosotros mismos con el lenguaje, mejores APIs podemos diseñar para que todos las usen. Si te emociona esta dirección, o si nunca has probado MSW antes, puedes hacerlo ahora mismo. Solo npm instala MSW y puedes simular cualquier API en cualquier lugar de tu pila completa.

Si quieres profundizar, sin embargo, pasé el último año trabajando con Ekhed en este nuevo curso que se llama Mock REST y GraphQL APIs con un trabajador de servicio simulado, donde vamos a construir juntos una aplicación de transmisión de películas completamente simulada primero, así contra servidores simulados. Y vamos a profundizar en los conceptos básicos de cómo empezar con la biblioteca e interceptar tu primera solicitud, a conceptos más avanzados como simular flujos y lidiar con consultas GraphQL y mutaciones e incluso un enfoque de esquema primero en la simulación. Así que es un lugar fantástico para empezar. Te animo a ver este curso y estoy seguro de que aprenderás mucho.

Por supuesto, puedes visitar el proyecto en sí en mswgs.io y también en GitHub. Lee sobre ello y si crees en la misión que estamos haciendo aquí, apóyala tanto económicamente como en términos de contribuciones, que realmente es el mejor apoyo. Y sí. Gracias.

QnA

Funciones Faltantes y Simulación de Solicitudes

Short description:

Existen algunas funciones faltantes en MSW en comparación con alternativas más antiguas, como una capa de expectativas para las solicitudes. Una característica anticipada es el soporte de la API VAPSocket. La generación automática de código MSW mediante el monitoreo de solicitudes de red es posible a través de paquetes del ecosistema, pero el soporte nativo puede usar HTTP Archive. MSW no simula solicitudes, sino que utiliza la API ServiceWorker para interceptar y responder a las solicitudes.

Entonces, vamos a entrar en materia. Hay bastantes, como dije. La primera aquí. ¿Hay alguna característica importante que actualmente falta en MSW en comparación con alternativas más antiguas y quizás más maduras? Creo que hay muchas características de expectativas, y eso es un juego de palabras. Como la gente está acostumbrada, por ejemplo, a usar NOC en pruebas, y a veces las personas quieren tener esta capa de expectativas. Como quieres realizar una solicitud, pero también esperas que tenga una carga útil particular o que se haya realizado una vez. Esta es una elección deliberada de que MSW no incluya esto y en cambio preferiría tener un paquete del ecosystem que amplíe el uso, porque no todo el mundo necesita estas expectativas. Y entonces, esto es algo que falta. Y creo que una de las características más anticipadas en las que espero tener tiempo para trabajar el próximo año sería, por supuesto, el soporte de la API VAPSocket.

Vale. Genial. Eso es bueno escuchar. Por supuesto. La siguiente pregunta aquí. ¿Podemos generar automáticamente el código MSW monitoreando las solicitudes de red de nuestra aplicación y actualizándolas cuando la estructura de respuesta cambia? Esta es una muy buena pregunta. Sé que mucha gente está haciendo magia loca, como derivar el código MSW de tus definiciones de tipo GraphQL de tus especificaciones de API abierta, de tus contratos empaquetados. Entonces, puedes encontrar todo eso en línea. Hay de nuevo, paquetes del ecosystem, gente construyendo esto. En cuanto al soporte nativo, creo, como dejándote un pequeño adelanto, preferiría mucho más tener HTTP Archive como el terreno común. Entonces, tal vez en el futuro, habrá algo alrededor de eso.

Vale. Muy bien. Estaremos atentos a eso, por supuesto. Sin promesas. Vale, entonces la siguiente pregunta. ¿Por qué no simplemente simular la respuesta en lugar de simular toda la solicitud? Hmm. No estoy seguro de entender completamente la pregunta, pero puedo elaborar un poco. Entonces, con MSW, en realidad no estás simulando solicitudes. Esto es algo que mencioné brevemente en una de las diapositivas que usamos la API ServiceWorker si hablamos de la interceptación del navegador, que permite que tu aplicación realmente haga solicitudes. Entonces, no hay stubs, y tus solicitudes ocurren y llegan a la red y simplemente reciben respuesta del ServiceWorker.

Soporte para TypeScript y Pruebas de Contrato

Short description:

Lo único que estás simulando es la respuesta. MSW siempre ha soportado TypeScript, pero se necesitan más materiales. MSW está escrito en TypeScript de forma nativa. MSW puede ser utilizado con herramientas avanzadas como PACT I-O para pruebas de contrato en pipelines de CI. MSW está diseñado para trabajar bien con otras herramientas y lograr diversos casos de uso. La compatibilidad con la API estándar es un enfoque. Sin los cambios de Node, el enfoque habría sido diferente, posiblemente contribuyendo a Node con FetchAPI.

Entonces, lo único que estás simulando es la respuesta. La parte de la solicitud está ahí solo para tener este contrato de colocación de solicitud-respuesta. Sí, está bien. Eso es bueno aclarar entonces. Sí. Muy bien.

¿MSW da soporte a TypeScript aún? MSW siempre ha soportado TypeScript, pero creo que mi error fue no proporcionar más materiales sobre eso. Escribí un artículo en Dev.Too, que supongo es uno de mis artículos más vistos, y debería haberlo sabido mejor, sobre el uso de MSW con TypeScript, pero estaba, como, basado en la versión anterior. Así que, en la nueva versión, quiero hacer algo mejor al respecto. Sería bueno tener ejemplos de código en la documentación que presenten TypeScript también. Así que, esta es una sugerencia de contribución para ti, si quieres añadirla. Sí. Así que, definitivamente funcionará mejor, pero MSW está escrito en TypeScript de forma nativa, por lo que siempre ha tenido este soporte genérico para el cuerpo de la solicitud, el cuerpo de la respuesta, los parámetros del cuerpo, e incluso las consultas y variables de GraphQL. Muy bien.

Así que, si eres nuevo aquí, las contribuciones a la documentación son bienvenidas. Siempre es un gran lugar para empezar con el código abierto, si aún no lo has hecho. Así que, sí. Las preguntas siguen llegando, así que seguiremos pasando por ellas. ¿Puedes proporcionar un caso de uso con MSW y pruebas de contrato en pipelines de CI? Sí, absolutamente. Creo que MSW es solo una forma de facilitar las pruebas de contrato. Así que, puede ser, como, en sí mismo, no lo hace porque es una herramienta muy simple de contratos de solicitud-respuesta, pero puedes usar algunas herramientas más avanzadas como PACT I-O, y puedes encontrar una forma de integrarlas. Sé que el equipo de PACT tiene una integración oficial. Creo que es PACT-MSW que puedes encontrar en npm. Y creo que utiliza MSW como solo un algoritmo de intercepción y utiliza PACT para pruebas de contrato y CI. Así que, definitivamente puedes hacer eso, especialmente si te gustan las pruebas impulsadas por contrato. Adelante.

Así que, me parece que, realmente, MSW está diseñado para hacer, como, lo que hace muy, muy bien y trabajar muy limpiamente con otras herramientas para lograr cualquier caso de uso que necesites. Sí, y una de las formas en que intentamos mejorar eso es exactamente apostando por la misma API estándar para que todos obtengan la compatibilidad. Sí, absolutamente. Como tengo curiosidad, si Node no hubiera salido con estos cambios, ¿crees que habrías tomado un enfoque diferente en algún momento o simplemente habrías seguido trabajando en tratar de hacerlo lo más utilizable y compatible posible? Creo que habría pasado otros dos meses arrancándome el pelo, y luego habría contribuido a Node con FetchAPI.

Uso de MSW en Pruebas y Beneficios de TypeScript

Short description:

El uso de MSW en diferentes niveles de prueba depende del producto y sus requisitos. Convencionalmente, el código de red se prueba en pruebas de integración, mientras que las unidades deben estar aisladas de las interacciones HTTP. MSW puede ser utilizado intensivamente en pruebas de integración e incluso en pruebas de extremo a extremo. TypeScript es crucial para los mantenedores, proporcionando pruebas estáticas y asegurando que la funcionalidad funciona. Contribuye a la experiencia del desarrollador y no tiene características de tiempo de ejecución. Los equipos también pueden explorar GS doc para comentarios de tipo.

Bueno, ahí lo tienes. Sí. Sabes, si no se está haciendo, hazlo tú mismo, supongo. Pero afortunadamente, como dijiste, se hizo, así que es genial verlo.

Bien, esta próxima pregunta, ¿recomiendas usar MSW con pruebas unitarias o solo con integración? Supongo que, al igual que con los niveles de testing, depende de dónde los dibujes y qué tipo de producto estás construyendo. Convencionalmente, pruebas el código de red en tus pruebas de integración. Tus unidades realmente deberían estar aisladas, y eso incluye el aislamiento de las interacciones HTTP. Así que la gente prueba intensivamente y usa MSW intensivamente en pruebas de integración. También puedes usar MSW en pruebas de extremo a extremo. Me gusta particularmente este concepto en el que ejecutas tu suite de pruebas de extremo a extremo contra simulacros y luego contra producción. Puede ayudarte a captar las pequeñas desviaciones. Pero por supuesto, si lo que estás construyendo realmente tiene que tener código de red en sus unidades, supongo que depende de ti. Sí, creo que estamos obligados a tener una respuesta depende por sesión de preguntas y respuestas. Así que eso es... Ahí lo tienes. Porque siempre lo hace. Siempre depende, ¿verdad? Sí. Sí.

Bien, entonces esta próxima pregunta, ya que crees que deberíamos trabajar en base a standards como JavaScript, ¿qué opinas de TypeScript? Y como ya respondimos a esto antes, ya se usa dentro de MSW. Pero, ¿podrías compartir tus ideas o pensamientos al respecto? Sí, me encanta TypeScript, aunque es un superconjunto y mucha gente lo entiende. Lo ven como un lenguaje diferente. Para mí es algo crucial como mantenedor, porque tengo toda esta funcionalidad para mantener y los tipos me proporcionan pruebas estáticas, básicamente. Y cuando tienes muchas características y mucha gente dependiendo de tu aplicación, es realmente crucial que mantengas la cosa funcionando. Y el contrato de tipo es una de las cosas. Aparte de contribuir a la developer experience, por supuesto, cuando publicas estos tipos, yo sé que hay mucho movimiento hacia GS doc, como usando solo comentarios de tipo. No lo he probado. Sé que funciona para algunos equipos. De nuevo, hazlo tú mismo. Haz tus propias conclusiones. No hay realmente nada en TypeScript de lo que tener miedo, porque al menos hasta donde yo sé, no introduce ninguna característica de runtime.

JavaScript, Fetch API y Herramientas de Desarrollador de Chrome

Short description:

Es un lenguaje completamente integrado. Apostamos por JavaScript, incluso cuando usamos TypeScript. El elemento más deseado es el progreso de carga para la API de Fetch. Las herramientas de desarrollador de Chrome introdujeron características geniales, pero el mocking de API no pertenece a una herramienta en particular. Debería ser una solución integral para una descripción de red consistente.

Es un lenguaje completamente integrado. Elimina los tipos y cada característica que obtienes es una característica de JavaScript. Así que apostamos por JavaScript, incluso cuando usamos TypeScript.

Muy bien, genial. Gracias por compartir eso. Así que esta es una buena pregunta aquí. ¿Qué está en la cima de tu lista de deseos, así que tal vez si fueras a construirlo tú mismo o desearlo para el futuro de las características de solicitud de respuesta de la API de JS?

Oh. Hmm. Realmente deseo que obtuviéramos el progreso de carga para la API de Fetch. Eso es probablemente una cosa que me hace usar XMLHttpRequest todavía. Y espero que tal vez algún día lo haremos. Vale. Y con suerte también. Si no, tal vez veremos un PR.

Muy bien. ¿Y qué piensas de las herramientas de desarrollador de Chrome y el mocking?

Sí. De hecho, escuché que el equipo de Chrome introdujo muchas cosas geniales recientemente. Puedes hacer mocks directamente en la pestaña de red, y luego tal vez incluso guardarlos o algo así. Creo que es realmente genial. Pero lo veo principalmente como un instrumento de depuración porque es más rápido. Es más accesible. Son DevTools al final, por lo que es tu tooling para debug y construir. Pero en cuanto a la solución integral, todavía creo que el mocking de API no pertenece a una herramienta en particular, incluso si es una herramienta de navegador. Puede ser una característica genial, pero si estás construyendo todo el producto, estás testing todo el producto y quieres que esta descripción de red sea consistente, al igual que demostré en las diapositivas. No son solo enchufes en diferentes áreas. Es solo una capa, luego se reutiliza en todas partes.

Sí. Y parece que quieres tener ese tipo de intencionalidad desde el principio cuando estás diseñando eso, ¿verdad?

Sí. Sí. Así que más proactivo versus reactivo, por así decirlo.

Soporte para WebRTC y Documentación

Short description:

Hay muchas cosas interesantes en Chrome DevTools. MSW proporciona primitivas para que los usuarios construyan sobre ellas. Es importante trazar la línea entre la responsabilidad de la biblioteca y los requisitos del usuario. En lugar de construir algo que lo haga por sí mismo, ilustrar los casos de uso con documentación y ejemplos es un enfoque mejor. El sitio web reconstruido de MSW tiene nuevas características como búsqueda y más recetas. El mocking basado en esquemas es posible con resolvers de mock, esquemas y tipos.

Sí. Eso tiene mucho sentido. Pero sí, hay muchas cosas interesantes en Chrome DevTools estos días. Por supuesto. Sí.

Muy bien. Entonces, ¿apoyarás el mocking de WebRTC? Creo que hay un problema al respecto desde hace dos años o algo así. Tal vez sea algo más. Creo que la postura sobre MSW, cualquier soporte que le brindes, es muy simple. Debería proporcionarte las primitivas y puedes construir sobre esas primitivas para lograr lo que quieras. Entonces, si quieres soporte DRPC, estoy casi seguro de que puedes hacer esto con MSW ahora mismo. Pero eso no significa que MSW deba enviarlo de forma nativa. Es una decisión bastante importante trazar esta línea donde termina la responsabilidad de la biblioteca y donde comienza el territorio del usuario con todos estos requisitos y casos de uso locos. Sí.

Como estábamos hablando antes, ¿verdad? Hace bien lo que hace. Sí. Se integra con otras herramientas. ¿Y crees que hay... En lugar de intentar construir algo que lo haga por sí mismo, tal vez solo ilustrando esos casos de uso, como con documentation o ejemplos?

Absolutamente. Una cosa que podemos hacer es simplemente mostrar ejemplos y de hecho reconstruimos el sitio web durante el año pasado. Así que es un sitio web completamente nuevo. Tiene documentación. Tiene búsqueda. Oh, eso es algo grande. Sí. Y estoy tratando de agregar más y más recetas, como streaming y como sondeo, usando generadores, muchas cosas que sé que la gente está usando, pero no todos saben. Como sé que tuvimos una charla con la gente de Apollo y estábamos iterando sobre cómo mejorar el mocking basado en esquemas. Y durante la charla me di cuenta de que no estoy haciendo un buen trabajo para promover que puedes hacer mocking basado en esquemas incluso ahora mismo. Puedes hacer resolvers de mock, esquemas de mock, tipos de mock. Es solo un problema de documentation.

Diferentes Enfoques para Simulacros y Pruebas

Short description:

Hay dos tipos de desarrolladores o probadores: aquellos que solo usan características documentadas y aquellos que usan todo, incluso de manera inapropiada. Como mantenedor, mi papel es cerrar esta brecha y proporcionar orientación. Los simulacros no son inherentemente malos, sino una técnica para establecer límites. MSW aborda la percepción histórica de la informalidad utilizando trabajadores de servicio y módulos de mutación. Depende de lo que estés probando y cómo lo construiste. Como cualquier herramienta, se trata de cómo la usas. Ahora, pasemos a la siguiente pregunta.

Sí. Siento que hay dos tipos de desarrolladores o probadores. Algunos... Si no está en la documentación, no creen que exista o tienen miedo de usarlo. Y luego hay otras personas que lo usarán para cualquier cosa y todo, incluyendo quizás cosas para las que no deberías usarlo. Y entonces, sí. Así que creo que hay algunas personas que probablemente ya han descubierto que funciona juntas, y hay otras personas que podrían usar un poco más de orientación.

Sí. Creo que como mantenedor, mi trabajo es cerrar esta brecha y acercar a estas personas. Sí, absolutamente. Muy bien. Todavía tenemos más preguntas y un poco más de tiempo para ellas. Entonces esta siguiente pregunta. Así que Venkat Subramanian dijo una vez, knockout antes de que te burlen. No había oído eso. ¿Podríamos solucionar el problema raíz en Fe con una mejor architecture e inyección de dependencias? No creo que haya nada particularmente malo con los simulacros. Es solo una técnica para establecer límites para que le digas a la prueba dónde debería terminar, dónde debería terminar tu sistema. Por sí solo, no es malo. Sé que históricamente tiene este aire de ser informal y punzante. Y esto es algo que estamos tratando de resolver en MSW utilizando trabajadores de servicio, utilizando un módulo como mutación en OGS. Pero supongo que todavía es otro. Depende de lo que estés testing y cómo lo construiste. Si construiste tu aplicación para ser amigable con la inyección de dependencias, entonces por supuesto puedes utilizarlo durante testing. Pero necesitas reconocer que esto crea un límite de testing diferente ahora.

Sí. Creo que es como dijiste, con cualquier herramienta o enfoque, no es inherentemente bueno o malo por sí mismo, sino cómo lo usas. Si tienes un martillo, puede ser muy útil para algunas cosas. Quizás no lo hagas para algo que requiere más precisión y eso no hace un martillo bueno o malo. Exactamente. Y entonces, sí, creo, de nuevo, te daremos dos esta vez para esta sesión de preguntas y respuestas.

Automatización e Integración de API con Postman

Short description:

La mejor herramienta para la automatización de API depende del caso de uso. Postman es popular, pero hay muchas opciones disponibles. La IA puede mejorar las pruebas, pero debe usarse de manera responsable. Controlar los datos de prueba puede ser un desafío, y automatizar el proceso sería beneficioso. La integración con Postman es posible, aunque los detalles pueden variar.

Depende. Entonces, bien, esta siguiente pregunta, ¿cuál es la mejor herramienta para la automation de API según tú? automation de API. Me pregunto si te refieres a testing o a un flujo de trabajo completo? Sé que Postman ha estado presente durante mucho tiempo. Lo he usado en el pasado un poco. Realmente no sé qué recomendar. Hay muchos de ellos por ahí. Creo que voy a decirlo. Depende, ¿verdad? Depende de lo que estés buscando automatizar, cuál es el caso de uso que estás intentando automatizar para tu API. Si estás haciendo testing de API automatizado, si estás haciendo cualquier tipo de migraciones, creo que dependerá de- Sí, especialmente con el auge de la IA en este momento, estoy bastante seguro de que hay algunas startups construyendo características realmente geniales, como semi-inteligentes de rascar tu API y dejarte descubrirlas. Asegurándose de que surgen nuevos proyectos todos los días. Sí, absolutamente. Y ya que mencionaste la IA y no hubo preguntas específicas al respecto, ¿cómo ves que eso podría impactar potencialmente en cómo pensamos sobre los datos de prueba del día o el mocking o de cualquier manera? ¿Es algo que ves integrándose bien o no? Creo que la IA, al igual que el mocking, es solo otra herramienta que puedes usar para potenciar tu experiencia. Uso GitHub Copilot o CodePilot cuando hago testing. Ayuda a escribir pruebas repetitivas cuando es fácil predecir lo que quiero probar, pero para pruebas más complejas, preferiría apagarlo. Así que de nuevo, es una herramienta que necesitas conocer. Es tu responsabilidad cuándo y cómo usarla y entender que a veces necesitas prestar atención extra a lo que la IA genera aquí. Sí. Y creo que, sé que lo mencioné antes, pero una de las razones por las que la gente recurre a los mocks es porque obviamente controlar tus datos de prueba puede ser muy difícil y generar los datos de prueba y crear las semillas. Así que si hay alguna manera de hacer eso desde el código de prueba o el código de la aplicación y manejar todo eso por ti, eso es algo que creo que sería un muy buen problema para resolver porque es un problema doloroso, doloroso. Puede ser. Puede ser, sí. Bien. Creo que tenemos tiempo para una pregunta más. Si tienes alguna otra pregunta para Artem, asegúrate de enviarla en Slido. ¿Es posible una integración alternativa con Postman? No estoy seguro. Supongo que implica MSW y Postman. Creo que sí. Francamente, no lo he usado en mucho tiempo para saber dónde podemos trazar esta línea común. Estoy seguro de que es posible de nuevo, porque MSW es una herramienta sencilla. Y luego Postman es una herramienta mucho más completa.

Soporte de Postman y Conclusión

Short description:

Espero que Postman admita archivos de red. Pruébalo. Postman está disponible para preguntas y chats. No dudes en interactuar con Artem para preguntas y respuestas. ¡Gracias por la presentación!

Espero que Postman admita algo como archivos de red. Y esto es de nuevo como donde podemos trazar la línea común tal vez. Así que no lo sé. ¿Por qué no lo pruebas?

Sí. Y Postman está aquí. Así que si quieres hacerles alguna pregunta o charlar con ellos, avísanos. Bueno, si tienes alguna otra pregunta o si no formulé tu pregunta de la manera correcta o no la abordamos, no dudes en charlar con Artem, expresar tus preguntas y respuestas, y escuchar alrededor de la conferencia.

Pero sí, muchas gracias por tu excelente presentación y por estar aquí. Sí. Mi placer. Gracias.

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

Test Effective Development
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!
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
TestJS Summit 2023TestJS Summit 2023
32 min
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
In this talk, we explore the divisive world of testing, where developers often find themselves torn between writing no tests and striving for 100% test coverage. Learn how to navigate these polarizing positions and adopt a more nuanced strategy that makes testing efficient and effective.We'll dive into the concept of 'Humble Views,' where we minimize untestable objects by extracting logic from UI elements into test-friendly parts of the codebase. This approach simplifies testing, focusing on business logic instead of UI complexities. Discover how the Model-View-Presenter (MVP) architecture helps achieve this, with presenters serving as a logical layer for testing and hooks aiding in separating logic from UI components.Throughout the talk, we'll discuss the trade-offs of this approach, the role of End-to-End (E2E) tests, and how to strike the perfect balance between too much and too little testing. Join us as we delve into the art of creating 'Humble Views,' ensuring that our React Native apps are scalable, maintainable, and effectively tested!
We May Not Need Component Testing
Vue.js Live 2024Vue.js Live 2024
26 min
We May Not Need Component Testing
Testings are mandatory and unit tests are the foundation for building a good testing system for our project. But for front end projects which involve components, how many unit tests are considered efficient and not overkill? Should we use additional libraries like Testing Library or Vue Test Utils with Vitest to test a component, when we can perform the same with just Playwright? Whether a component test using an E2E framework like Playwright is really a kill for? Let's find out in my talk.
Safely Handling Dynamic Data with TypeScript
Node Congress 2021Node Congress 2021
29 min
Safely Handling Dynamic Data with TypeScript
TypeScript makes JavaScript safer adding static type definitions. Static definitions are wonderful; they prevent developers from making trivial mistakes ensuring every assignment and invocation is done correctly. A variable typed as a string cannot be assigned a number, and a function expecting three arguments cannot be called with only two. These definitions only exist at build time though; the code that is eventually executed is just JavaScript. But what about the response from an API request? In this talk Ethan Arrowood, Software Engineer 2 @ Microsoft, he will cover various solutions for safely typing dynamic data in TypeScript applications. This talk features popular technologies such as Fastify, JSON Schema, Node.js, and more!
Component Testing With Vitest
TestJS Summit 2023TestJS Summit 2023
29 min
Component Testing With Vitest
Testing is important. Proper unit tests can eliminate the chance for bugs to appear. But which testing framework will be suitable? Let’s explore how we can develop a reliable and efficient strategy for component development and testing with Vitest
Securing Node.js APIs with Decentralised Identity Tokens
JSNation Live 2021JSNation Live 2021
9 min
Securing Node.js APIs with Decentralised Identity Tokens
Authentication and Authorization are serious problems. We often dedicate a lot of time to craft powerful APIs but overlook proper security measures. Let's solve it with Magic using a key-based identity solution built on top of DID standard, where users’ identities are self-sovereign leveraging blockchain public-private key pairs. In this talk, we’ll look at proper ways to secure our Node.js APIs with Decentralised Identity Tokens. We’ll go from learning what Decentralised Identity standards are, how the users’ identities are self-sovereign leveraging blockchain public-private key pairs, why they’re the future of API security, and to put theory into practice we will build a real-world implementation using Node.js where I’ll show common best practices.