Mock Service Worker 2.0

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.