Todo lo que necesitas es un contrato...

Bueno, permítanme aclarar la sala. No va a haber contrato testing aquí. Esta es una broma de la que estábamos hablando antes de subir al escenario. Además, me voy a mover mucho, así que estoy tratando de averiguar el lugar. Eso está bien, si no me ciega la luz.

Antes que nada, React Advance, muchas gracias por tenerme aquí. Es un placer. Caminaré por ese lugar porque aparentemente la cámara no me captará en el otro, así que intentaré no moverme mucho.

Solo quería comenzar esta charla con, me gustaría dar un aplauso alegre, porque hubo mucho trabajo duro para preparar esta conferencia para todos de Git nation, todos del equipo técnico. No sé si están al tanto, pero cuando comenzamos hoy, tuvimos algunos problemas para conectar todo, y ahora todo ya está funcionando hasta ahora, ¿puedo obtener un todos los que están trabajando en esto? Vale. Muchas gracias.

Entonces, comencemos esto porque ya pasó un minuto, y realmente hay tres cosas que me molestan como desarrollador. La primera es cuando tienes un código inmantenible. Conoces la sensación. Tu código no es realmente tan bueno a veces. Cuanto más agregas, peor se pone. Es difícil. Sí, es duro. Y luego la segunda cosa que realmente me molesta, es cuando esa inmantenibilidad encuentra una forma de meterse en tus pruebas. Ahora no es malo que tu código no sea bueno, tus pruebas tampoco son buenas. Probablemente no estás durmiendo tan bien por la noche porque sabes lo que se siente tener pruebas inestables. Y la tercera cosa que realmente me molesta, y prometo no empezar una diatriba aquí, es cuando tienes una tarea que llega tarde al sprint. Sé que algunos de ustedes se relacionan con la sensación. Imaginemos que tenemos un equipo donde dos partes están trabajando en una tarea y la primera parte toma el 98% del tiempo, y una vez que la tarea llega a ti, tienes el 2% del tiempo. Así que obviamente tu gerente de producto va a esperar que entregues eso ayer. Y este es un sentimiento del que podría empezar a hablar aquí y no pararía.

Así que continuemos, porque tengo una historia sobre cómo yo y mi equipo solucionamos estos problemas hace un par de años. Así que comencemos desde el principio sobre cómo acabamos de solucionar el primer problema. Yo y mi equipo acabamos de derrotar al monstruo del código inmantenible. Porque esto había sido algo que estaba rondando, nos amenazaba, era duro.

¿Y cuál era la razón? Bueno, la razón era el estado del servidor. No sé si están al tanto de lo que es el estado del servidor. Normalmente es el estado que existe en algún lugar de Internet como externo a su aplicación. Y tiene un montón de desafíos. Caché, deduplicación de solicitudes, data prebúsqueda. Hay un mantenedor aquí de React Query del que puedes hablar de muchos de estos desafíos y probablemente puedes entender cuánto dolor es entender y tener que implementar esto a mano y puedo decirles que mi equipo y yo, no teníamos React Query en aquel entonces o al principio, no lo teníamos. Así que estábamos implementando todas estas cosas por nosotros mismos y cuanto más código teníamos, peor se volvía el monstruo del código inmantenible. Así que empezamos a pensar, ¿por qué estamos implementando esto nosotros mismos de nuevo? ¿Qué estamos tratando de demostrar al ir en esta dirección? Y bueno, pasaron un par de meses y fue cuando un par de, bueno, estos meses pasaron un compañero de trabajo, como el Rey Arturo en la película de la Espada y la Piedra. Creo que así se dice en inglés. Lo siento, hablante no nativo de inglés aquí. Un compañero de trabajo se acercó a la piedra y sacó una consulta de 10 pilas. Así que aparentemente, esta nueva cosa, React Query, acababa de aparecer y era la solución para nuestros problemas. Y la consulta de 10 pilas trajo armonía a nuestro código porque ahora todos los problemas e inconvenientes que teníamos con el estado del servidor se resolvieron y no tuvimos que preocuparnos por implementar eso por un tiempo.

Ahora, una nueva amenaza se cernía en las sombras. Verás, esa inmantenibilidad encontró una forma de salir de nuestro código y entrar en nuestras pruebas. Ahora, no sé si recuerdan esta imagen que les mostré hace un par de minutos, pero esto es Hydra. Y ya saben lo que dicen de las Hidras. Corta una cabeza, dos más toman su lugar. Y esto es más o menos lo que empezaba a suceder con nosotros porque ahora nuestras pruebas no solo eran inmantenibles. Eran defectuosas. Eran complejas. No podía dormir por la noche porque no confiaba en lo que estaba haciendo y ahora te preguntas, ¿cuál es la relación? ¿Qué vamos a ver? Bueno, ahora, hace un par de años puedo decirles que mi equipo y yo logramos solucionar estos problemas. Y la parte divertida fue que todo lo que necesitábamos era un contrato. Así que esta es la parte donde realmente empiezo la charla.

Permítanme presentarme rápidamente. Soy Daniel Alfonso. Trabajo como defensor del desarrollador en OLX. Soy instructor de AGIT y embajador de Out-there y puedes encontrarme, voy a decir Twitter debido a la encuesta anterior en Twitter y prácticamente en cualquier red social al final Así que Daniel GC Alfonso. También algo sobre mí, recientemente publiqué un libro llamado State Management con React Query. Gracias.

También me encantaría hablar con cada uno de ustedes sobre React Query porque verán en esta charla que es algo que realmente me encanta. Otra cosa, estoy totalmente a favor de compartir amor. Y quiero agradecer a Joshua, Mateus y Tejas porque me dieron comentarios sobre versiones anteriores de esta charla y esto me permitió mejorarla y tener la charla que tenemos hoy. Así que por favor estén atentos para esa charla. ¿Puedo recibir un aplauso para ellos? Solo allí compartiendo el amor.

Vale. Realmente rápido porque pasaron cinco minutos. Esta charla va a ser un estudio de caso. Les voy a mostrar algunas de las cosas. Ya les mostré algunos de los problemas que mi equipo y yo tuvimos y cómo los solucionamos. Obviamente, mientras estoy presentando, algunos de ustedes podrían estar pensando, oh, yo no lo habría hecho de esta manera o probablemente lo habría hecho de esta manera. Bueno, eso es lo que pasa con la implementación y la creación de software hoy en día. No siempre tienes todas las respuestas. Afortunadamente ahora teníamos algunas de ellas. Pero cuando empezamos a hacer esto, no era el mejor escenario. Entonces, si tienes la pregunta de por qué no hiciste esto o por qué no hiciste eso? Bueno, probablemente no lo pensamos. O si lo hicimos, no hay razón para entender por qué.

Así que solo para recapitular rápidamente lo que estaba mencionando. Ahora teníamos un problema con la inmantenibilidad en nuestras pruebas. Eso no estaba funcionando bien. Y cuando digo prueba, en este escenario, estoy hablando de pruebas unitarias e integración. Y eso... Ups. Vale. No voy a moverme de nuevo porque parece que fue cuando me moví. Eso era difícil. Porque no sé si están al tanto de cuáles son los desafíos en pruebas de interacciones con el estado del servidor. Pero vamos a recapitular rápidamente. Vale.

Vamos a averiguar si algo está pasando. ¿Tenemos señal allí atrás? Eso es lo que voy a hacer. Vale. Está apareciendo de nuevo. Entonces... Veamos. Vale. ¡Woo! Se ha hecho. Entonces... Normalmente lo que sucede cuando estamos haciendo interacciones y haciendo solicitudes de obtención de data, tenemos el navegador y el navegador envía una solicitud a internet y el internet responde con los data. Eso es más o menos lo que sucede normalmente. Así que ahora vamos a... Y voy a seguir hablando mientras intento averiguarlo porque esto está preparado. Ahora hay otro escenario. Así que lo que deberías estar viendo aquí es una imagen en las pruebas. Así que ahora en el escenario tenemos pruebas. Y en nuestras pruebas, no queremos que esto suceda. No queremos ir realmente a internet para obtener los data porque eso significaría que probablemente obtendríamos diferentes data cada vez. Eso significaría que tendríamos pruebas inestables. Y eso probablemente significaría, una vez más, que no dormirías bien por la noche.

Así que mi equipo y yo tuvimos que descubrir las mejores soluciones para lidiar con la simulación de data que provienen del estado del servidor. Así que empezamos con simulaciones manuales al principio. Estábamos usando Jest, Jest FN, un montón de cosas de simulación manual. Y funcionó por un tiempo. Pero cuanto más código añadíamos, peor se ponía. Porque ahora teníamos que mantener un montón de estas cosas. Y luego llegamos al otro escenario. OK, vamos a añadir el adaptador de simulación de Axios. Porque estábamos usando Axios como el cliente.

Así que ahora estábamos manteniendo simulaciones manuales. Y también estábamos manteniendo escenarios de adaptador simulado de Axios. Y luego puedo jurar, en cierto punto, incluso había algún tipo de magia. Alguna brujería. No tengo idea de lo que ese código todavía hace hasta el día de hoy. Solo sé algo. Cada vez que tenía que actualizar las simulaciones manuales, las simulaciones manuales romperían el adaptador simulado de Axios. Cada vez que tenía que romper, usar, actualizar el adaptador simulado de Axios, esa cosa rompería la magia. Y lo adivinaste. Cada vez que cambiábamos cosas en la magia, rompía la otra cosa. Así que este era el ambiente al escribir pruebas cada vez que teníamos que hacerlas.

Era estresante. No estaba funcionando para nosotros. Queríamos una solución ideal. Queríamos algo que funcionara mejor para nosotros. Y nos permitiera deshacernos de todas las cosas que teníamos antes. Entonces, en un escenario ideal, ¿qué tal si pudiéramos tener una solución que interceptara todas las solicitudes? ¿Un lugar local? ¿No tendríamos que hacer ninguna configuración en el entorno de testing? Y al usar un contrato que usamos para especificar la API y los data que esperábamos para ello, al usar esa cosa, podríamos probar nuestra aplicación y no preocuparnos. Y este sería el escenario ideal. Y realmente, eso es lo que tenemos. Pero no sabíamos qué solución nos convendría. Y fue entonces cuando llegamos a conocer esta cosa llamada trabajador de servicio simulado.

Entonces, el trabajador de servicio simulado, para aquellos de ustedes que no lo saben, es una biblioteca de simulación de API que utiliza trabajadores de servicio, una API de ServiceWorker, para interceptar solicitudes reales. Así que sé lo que algunos de ustedes podrían estar pensando. Pero espera, estamos hablando de testing, así que probablemente sea en un entorno antiguo. Los trabajadores de servicio solo funcionan en el navegador. ¿De qué estás hablando? Entraremos en ello un poco. Pero repasemos cómo funciona el trabajador de servicio simulado un poco antes de continuar la historia. Así que ya vimos esta cosa. Normalmente, cada vez que necesitamos algunos data, el navegador hace una solicitud, y el Internet nos devuelve los data. Ahora, con el trabajador de servicio simulado, hay algo nuevo.

Hay un tercer usuario en este escenario. Así que hay un ServiceWorker justo en medio. Así que cada vez que hay una solicitud del navegador, el ServiceWorker va a interceptar esa solicitud. Va a verificar el contrato que has definido dentro de él, y utilizando ese contrato, decidirá qué data devolver. Así que, en resumen, puedes tener una forma de devolver data simulada desde allí.

Ahora, algunos de ustedes podrían estar pensando, está bien, pero ¿qué sucede en el escenario en que no tenemos un contrato especificado? Bueno, en este caso, simplemente vamos a Internet, dejamos que el navegador haga la solicitud normal que haría, y luego obtenemos los data de vuelta, devolviéndolos al navegador. Y eso es básicamente la esencia de cómo funciona el servicio de simulación.

Ahora, para entender un poco más cómo funciona esto, solo voy a mostrarles algunos fundamentos de esto. Así que el primero son los manejadores de solicitudes, y el segundo son los resolutores de respuestas. Los manejadores de solicitudes son responsables de hacer algo, que es, bueno, básicamente especificar el contrato, la API y la ruta a la que vas a acceder. Así que permíteme abrir esto aquí. Oh, no quiero dibujar. Esto pasó la última vez. Así que intentemos volver aquí. Esto es lo que sucede cuando intentas cosas nuevas en el escenario. Veamos si puedo deshacerme de él. Inténtalo de nuevo. Todavía está allí, pero ignoremoslo por un momento porque no parece que pueda quitarlo. Así que en este escenario, lo que está sucediendo es que estamos importando la API REST. Así que básicamente estamos diciendo, está bien, vamos a tener una API REST, y cada vez que obtienes una solicitud GET, juego de palabras no intencionado, supongo, a la ruta, Daniel GCFomes, vas a devolver un resolutor de respuesta. Y eso es básicamente la esencia. Así que estás definiendo básicamente qué protocolo estás usando, qué tipo de escenario vas a manejar, en qué ruta vas a acceder. Pero la parte divertida de Mock Service Worker es que también funciona con GraphQL. Así que tienes REST. Si tienes un escenario GraphQL, puedes importar GraphQL, y dices, cada vez que hay una consulta para obtener usuarios, devuelves este resolutor de respuesta. Así que todo esto que tenemos aquí, es un manejador de solicitudes. Lo que tenemos aquí es un resolutor de respuesta. Desde el escenario del resolutor de respuesta, y déjame tomar esta parte de aquí, el escenario del resolutor de respuesta lo que haces básicamente allí es especificar los data que vas a devolver cada vez que se accede a esa ruta. Así que cada vez que tenemos una solicitud GET a Neo4j CFoS, en este caso, devolviendo una respuesta, que dentro va a devolver el objeto JSON, en este caso, con el nombre John, y la edad 38. Y eso es básicamente la esencia de cómo puedes establecer tu propio contrato con Mock Service Worker.

Ahora volvemos a la parte donde dije, está bien, esto funciona en la prueba. Porque mientras los Service Workers se ejecutan en el navegador, Mock Service Worker también tiene un paquete de interceptación de nodos que te permite ejecutar en entornos de nodos. Y así es como funciona esto en las pruebas.

Entonces, si configuras un worker, puedes usar una API de configuración de worker para decir, está bien, quiero configurar este service worker que va a usar este contrato que definí, y cuando el navegador lo detecte, va a devolver los data. En otro escenario, puedes decir, ahora en otro entorno, quiero configurar un servidor, y este va a escuchar para mi prueba. Entonces, cuando mi prueba dispara una solicitud, esa cosa va a devolver los data. Entonces, desde un ejemplo que tenemos aquí, estamos configurando un worker, por lo que estamos configurando un service worker con el manejador de solicitudes que acabamos de ver. Cada vez que hay una solicitud GET a Daniel J. C. Afons, va a devolver el primer nombre Daniel, apellido Afons. Y luego lo que hacemos, iniciamos el worker. Y esto es prácticamente toda la configuración que necesitas hacer en el navegador para que funcione el mock service worker.

Bueno, eso fue divertido. Vale. Entonces, volvamos a presentar un escenario una vez más. Hay una solicitud GET a Daniel J. C. Afons. El service worker va a interceptarlo. Entonces, lo que va a hacer es preguntarse, ¿tengo un manejador de solicitudes definido? Y si es así, va a devolver los data. Y esto es prácticamente lo que vimos anteriormente. En el escenario en que intenta llegar a una ruta que no tenemos definida, como random, todavía se preguntará, oh, no tengo algo. Entonces, vamos a Internet, dejamos pasar la solicitud y la enviamos de vuelta. Y esto es prácticamente lo que nos ayudó a salvar nuestras pruebas. Porque ahora solo había tres pasos que teníamos que seguir para deshacernos de toda esa insostenibilidad que teníamos. El primero es eliminar todos los MOCs. Eliminar todos los MOCs manuales, todos los adaptadores de mock de acceso. Eliminar toda esa magia, todo eso. Fue la mejor parte. Me encanta eliminar código.

Esas pobres solicitudes son increíbles. Simplemente vas allí, como, oh, se ha eliminado tanto código. Es tan bueno.

Luego miramos los contratos, los contratos de las APIs que estábamos utilizando, así que simplemente fuimos allí, definimos todos los manejadores de solicitudes para nuestra API e iniciamos nuestro servidor antes de nuestras pruebas. Y así de simple, nuestras pruebas unitarias e integradas estaban funcionando. No eran inestables porque ahora solo había una única fuente de verdad para los data que estábamos obteniendo, y esto fue prácticamente yo y mi equipo después porque ahora podíamos descansar un poco y relajarnos porque ahora podíamos dormir por la noche. Así que teníamos que confiar en las pruebas que estábamos construyendo.

Ahora, recuerda, había un tercer escenario, que es la tarea que llega tarde durante el sprint, y el mock service worker también solucionó eso curiosamente, así que repasemos lo que estaba pasando en mi equipo. Normalmente, teníamos sprints de dos semanas, y mi equipo estaba compuesto por desarrolladores backend y por desarrolladores frontend, y lo que solía suceder cuando intentábamos construir una nueva implementar las respectivas pantallas para eso era que el backend se tomaba todo este tiempo trabajando en una tarea. Y no estoy criticando aquí. Construir una API es difícil. Hay tantas cosas que tienes que construir. No podían acelerarlo lo suficiente. Pero esto también significaba que durante el tiempo que estaban haciendo esto, teníamos que hacer algo más. Estábamos construyendo algunas tareas más pequeñas no relacionadas, algunas tareas más pequeñas, y algunas tareas más pequeñas hasta que solo quedaba esta pequeña cosa aquí. Y si recuerdas mi introducción, este era el tiempo que nos quedaba para salvar el sprint. Así que era ese 2%. Y esto, como dije, causó la lucha. Estábamos señalando con el dedo. Estábamos como, necesitamos entregar esto más rápido. El PM está encima de nosotros. Queremos enviar esto más rápido a los usuarios. Lo entiendo. Queremos hacer nuestro trabajo como desarrolladores. Es nuestro principal objetivo. Pero cuando tienes un ambiente como este, es un poco estresante. Y ahora podemos empezar a hablar de estas funciones de equipos y procesos ágiles y lo que sea. Probablemente podríamos haberlo hecho mejor. Pero este fue un escenario en el que este software solucionó nuestro problema. ¿Por qué? Alguien dijo, hey, mira.

Mock service worker se ejecuta en el navegador, ¿verdad? Así es. Genial. Entonces, ¿qué pasa si definimos un contrato mientras estamos comenzando el sprint? Y alguien dijo, está bien. Pero, ¿por qué? ¿Cuál es la razón de eso? Porque escúchame. Si definimos un contrato con todo el equipo juntos, podemos entrar en mock service worker y definir los resolventes de solicitudes. Podríamos especificar el contrato. Sí. Y luego podemos iniciar esto en el navegador. Sí. Te estoy siguiendo. Y entonces prácticamente vamos a tener una API que está simulada para data. Mientras la API aún no está lista. Entonces, esto significa que mientras el backend aún está trabajando en la tarea, podemos trabajar en la tarea al mismo tiempo porque ahora hemos definido el contrato y luego trabajamos contra la API simulada. Una vez que terminamos, eso ya está en desarrollo o en ambiente de QA, lo encendemos contra la API correcta y la probamos. Y funcionó, solucionó ese problema porque ahora estábamos emparejando trabajo, estábamos enviando más rápido y ya no estábamos estresados. Luego tuvimos tiempo para seguir trabajando en las tareas más pequeñas, pero ahora no estábamos estresados al final del sprint para entregar cosas para ayer. Hizo todo mucho mejor para nosotros. Y una vez más, solo tuvimos tres pasos para salvar nuestro sprint. Definir el contrato al principio. En segundo lugar, crear todos los manejadores de solicitudes y resolventes de respuesta. Y finalmente, iniciar el service worker. Estos tres pasos que funcionaron en el testing también funcionaron en el escenario ahora para solucionar esta disfunción que yo y mi equipo teníamos. Nos dejó a todos celebrando al final porque se sintió bien.

Ahora no teníamos que discutir al final de cada sprint. Al llegar al final de mi charla, quiero compartir algo de amor. Artem, el creador de mock service worker, tiene esta gran serie de publicaciones en su blog sobre mock service worker. Donde va desde toda la concepción de lo que llevó a su creación, todos los desafíos, y recientemente anunció un curso sobre eso. Estoy súper emocionado de ver cómo se está desarrollando esa cosa. Solo compartiendo algo de amor, sigan a Artem porque mock service worker es genial.

En los últimos dos minutos de mi charla, solo quiero llevar algo a casa desde aquí y recordarte algo, que es, los ingenieros liderados por organizaciones entregan cosas asombrosas para nuestros usuarios. Nuestros usuarios quieren estas cosas para ayer. Las quieren rápido y las quieren funcionando. Siento que muy a menudo, y mi equipo y yo sufrimos mucho por eso, estábamos quedándonos atrapados en este ciclo de complejidad. Nos estábamos quedando atrapados en lo que se llama ingeniería de soluciones versus resolución de problemas. Nos estábamos quedando atrapados en el Hazlo Tú Mismo, la sobreingeniería. Estábamos atrapados en todas estas pruebas porque dijimos, oh, vamos a implementar todas estas cosas por nosotros mismos. Lo que no nos dimos cuenta allí es que estábamos perdiendo tiempo. Estábamos perdiendo tiempo que podríamos estar entregando cosas más rápido a nuestros usuarios. Si estamos perdiendo tiempo, estamos desperdiciando el dinero de nuestra empresa. Entonces, lo que estoy predicando aquí y me gustaría que pensaras es, antes de que te sumes al modo de sobreingeniería de Hazlo Tú Mismo, piensa en algo. Probablemente alguien más en el mundo ya tuvo el mismo problema que tú, y probablemente ya se adelantaron y publicaron un paquete de código abierto. Y probablemente ese paquete está mantenido, está probado, es seguro, y tiene incluso más escenarios que las cosas que consideras hoy en día. Así que por favor considera eso. Porque tenemos tantos grandes proyectos de código abierto, tenemos tantos mantenedores de código abierto aquí con nosotros hoy. Así que echa un vistazo a esos proyectos antes de entrar en el modo Hazlo Tú Mismo. Entonces, si hubiera conocido 10 stack query antes, probablemente, como dije, habría ahorrado mucho más dinero a mi empresa y a mi equipo. Si hubiera conocido mock service worker antes, habría ahorrado incluso más dinero. Habría ahorrado horas de sueño, que, si te sientes como yo y tienes muchos insomnios, empeora cuando tus pruebas no están funcionando. Así que sí, estas herramientas salvaron un poco la forma en que estaba construyendo software. Y son mis favoritas. Prácticamente en cada proyecto que construyo hoy en día, las instalo, porque, bueno, me ahorraron mucho tiempo, me ahorraron muchas preocupaciones. Y realmente confío en todo lo que necesito. Y eso fue un dato curioso en todas estas cosas.

El dato curioso que solucionó todos los problemas que mi equipo y yo teníamos al final, fue que todo lo que necesitábamos era un contrato.

Entonces, muchas gracias, React Advanced. Estaré ahora para la sesión de preguntas y respuestas, ¿verdad? Tenía preparado un chiste. Tenías un chiste. Sí, y se me olvidó completamente. Se me olvidó completamente. Así que probablemente incluso si lo encuentro, ya no es gracioso. Pero gran charla. Gracias por compartir.

Vamos a saltar a la audiencia. Veamos qué tienen que decir las personas. Sí. Lo siento, también los estoy mirando allí. Así que hay algunos chistes allí, pero puedo leerlos aquí, pero recibí un mensaje de nuestras esposas. Oh, ¿todo está bien? Bien. Solo bromeaba. Solo bromeaba.

¿Qué pasa si el contrato cambia durante el sprint? Esto me pasó la semana pasada. Pregunta de Anónimo. Gracias, Anónimo. Esta es probablemente la pregunta más respondida cada vez que doy esta charla. Y es gracioso, porque eso también me pasó a mí. Pero diría que por lo general los cambios de contrato que ocurren no van a ser tantos, esperemos, a menos que vayan y reescriban todo. Pero habrá algunos escenarios en los que tengas algunos cambios de contrato más pequeños. Y cuando hay cambios de contrato más pequeños, probablemente sea más fácil volver atrás, verificar ese escenario específico que para todo el contrato. Y al final del día, todavía tienes que repasar el trabajo que hiciste, pero no va a ser todo al final del sprint y tener que entregar todo al mismo tiempo. Así que el pedazo con el que vas a tener que trabajar va a ser un poco menos comparado con todo lo que pasaste antes. No sé si eso responde a la pregunta, espero que sí, pero esa es más o menos la pregunta más común que recibo cada vez que hago esta presentación. Sí. Nueve de cada diez veces, el contrato no cambiará.

Entonces ahorrarás tiempo y esa una de cada 10 veces, bueno... Sí, gran resumen. Sí, ese es el resumen. Sí.

Otra pregunta de nuestro activo cuestionador, anónimo, ¿cómo cambias la respuesta simulada por prueba para que puedas probar diferentes escenarios en una especificación de prueba? Sí. Esa es una de las partes que tuve que recortar porque usualmente al final de esta charla tengo una pequeña demostración, pero bueno, tenemos 20 minutos. Básicamente puedes definir todo el contrato, tiene respuestas, es solicitud respuesta, resolutores y respuesta. Olvidé cómo hablar, lo siento. Como Sara estaba diciendo hace un par de minutos, el inglés no es mi lengua materna no mi inglés nativo, lo siento, mi cerebro acaba de ir a responder a esto. Básicamente puedes definir todo el contrato, pero luego para cada prueba específica puedes seguir adelante, puedes obtener acceso a la instancia del servidor que estás utilizando, o en este caso al, sí, a la instancia del servidor y puedes decir, vale, para esta prueba específica, quiero que uses este resolutor de respuesta. Y puedes decir sólo para esta prueba específica, lo anulas. Y luego todo después de eso, se restablece al valor por defecto. Así que básicamente puedes personalizar escenarios específicos para pruebas específicas, lo que lo hace un poco más simple que, por ejemplo, configurar cosas como un servidor simulado, si has tenido experiencias de configurar servidores simulados, eso es un gran dolor, especialmente en escenarios como este, porque entonces tienes que seguir adelante y decir, oh, vale, para este escenario específico, cuando recibo este parámetro, quiero que lances un error. Con el trabajador de servicio simulado, no necesitas simplemente importar el servidor que estás utilizando para escuchar todo y decir, vale, para esta prueba específica, estoy haciendo esto y simplemente funciona de inmediato. No es mucha la configuración que necesitas hacer para eso. Genial. Gracias.

Siguiente pregunta de Anónimo, ¿cómo mantienes el contrato? ¿El trabajador de servicio simulado importa Swagger, por ejemplo? Oh, esa es una gran pregunta. He estado tratando de ver si eso existe por un tiempo. Creo que aún no existe. Así que hay una oportunidad, si alguno de ustedes quiere probarlo. He estado queriendo hacerlo, pero aún no he tenido tiempo. Así que usualmente lo que he estado haciendo es, el contrato que tenía en mi equipo, usualmente cuando construyes APIs, o añades la mayor parte de él, o puedes eliminar. Pero es fácil de eliminar. Es sólo ir allí y borrar. Y cuando hay pequeños cambios, puedes ir allí en un escenario específico y simplemente ajustarlo manualmente. Obviamente sería ideal si tuviéramos algo que pudiera mejorar importar desde Swagger, como este ejemplo aquí. Sería realmente bueno, pero hasta donde sé, aún no existe. Puedo preguntar a Artem, y trataré de volver a esto en Twitter o en LinkedIn, pero sería realmente, realmente bueno. Genial.

Correcto. Estaré pendiente de tu Twitter entonces. La siguiente persona está utilizando una API simulada basada en express, y quiere saber si hay alguna ventaja en usar o cambiar a MSW, Ordenador de Servidor Simulado. Estaba en camino aquí. Estaba charlando con algunos de los otros oradores y estaba diciendo, eliminé una diapositiva sobre por qué no usé un servidor simulado en su lugar? Y alguien va a preguntarlo. Así que aquí está la pregunta, y tengo las respuestas preparadas para ti. Así que primero hay como cinco pasos para esta pregunta. Primero, los servidores simulados necesitan configuraciones. Tuviste que hacer un montón de configuraciones del servidor simulado, mantenerlo, configurarlo para que se ejecute en pipelines o donde sea y todas esas cosas. Por ejemplo, hay otra cosa que es usualmente, si una de las pruebas falla y rompe el servidor simulado, todas las otras pruebas fallarán después, así que hay un montón de desventajas que podrías nombrar para estas cosas. Para mí, lo que realmente me gusta de usar el trabajador de servicio simulado en lugar de esto es primero, no tienes mucha configuración. Una vez que tienes el contrato, no tienes tanto mantenimiento y no tienes que preocuparte por todos los otros escenarios. Como mencioné, por ejemplo, la última pregunta que tuvimos para simplemente anular un escenario para una prueba específica. Di el ejemplo de si estamos usando un servidor simulado, tendríamos que ir allí y configurar sólo un escenario específico. Así que siempre que haya este parámetro específico, vas a lanzar un error con el trabajador de servicio simulado. Simplemente importas lo que sea que añadas y dices para aquí, lanza un error. Así que en su mayoría, no tienes que configurar cosas separadas a un lado. Puedes incluir esto en tu propia solución porque el trabajador de servicio simulado está alrededor de tus propios proyectos y la otra mejor parte, no necesitas cambiar configuraciones en tus pruebas para apuntar al servidor simulado cada vez que estás ejecutando la prueba, simplemente inicias el servidor en, eso es prácticamente todo con el trabajador de servicio simulado. Genial. Gracias. La siguiente pregunta es de Jack. ¿Cómo evitas simplemente re implementar el backend en tu trabajador de servicio simulado por ejemplo para probar las respuestas dinámicas basadas en los parámetros? Esa es también una gran pregunta. Um, para este escenario.

Entonces, permíteme prevenir solo, está bien. Entonces, para este escenario, la mayoría de las veces no he tenido esta experiencia. No lo he hecho, la mayoría de las veces es solo un simple simulacro de cáncer, um, solo algo de Jason o lo que sea, o algunas transformaciones de salida sobre las cosas que teníamos. Si necesitas estas respuestas dinámicas, entonces para cada prueba específica, puedes simplemente anularla en esa prueba específica. Entonces, si estás haciendo un caso de prueba en ese escritorio, puedes simplemente decir, está bien, aquí quiero que devuelvas esto en lugar de devolver eso. Y de esta manera, evitas tener que programar, tener simulacros dinámicos en tu contrato, en lugar de tener todo configurado por separado. Así que en su mayoría simplemente pasas la responsabilidad de la prueba que estás haciendo para darte la respuesta que necesitas en lugar de agregar todas las demás cosas en los manejadores de solicitudes.

Muy bien. Gracias, Jack. Y gracias Daniel. Primero, la siguiente pregunta es, ¿los simulacros son comprobados estáticamente contra el esquema GraphQL? Esa es una gran pregunta. No sé la respuesta a esta, para ser honesto, no he tenido mucha experiencia utilizando estos con GraphQL. Hice algunas demostraciones, pero principalmente los entornos en los que he estado trabajando son basados en rest Te sugeriría que revises la documentation porque es realmente, realmente buena. Y ahora están a punto de lanzar la V2 de MS-Double. Algunas cosas podrían cambiar. Así que sí, mi sugerencia aquí es revisar la documentation y si tienes una pregunta específica esta pregunta específica, puedes simplemente ir a Twitter y etiquetar a Artem y probablemente te dará la retroalimentación, ¿verdad? Como necesites. Así que él es la fuente de verdad para esto. Quizás Lenz todavía está aquí. No lo sé. Quizás él sabe. Ya se fue. Nos dejó. Pero lo averiguaremos. También intentaré preguntar y trataré de volver a la persona que hizo esta pregunta, anónima, intentaré encontrar a esta persona. Buena suerte. Mantenme al día. Vale.

Oh, anónimo es otro. ¿Puedes definir diferentes servidores simulados con manipuladores variables para solicitudes en ejemplo, basado en diferentes estados de una aplicación. Vale. Entonces diferentes simulacros con variables. Vale. Entonces quieres manipuladores específicos dependiendo del escenario. ¿Es eso, estoy tratando de entender esta pregunta. Entonces define diferentes servidores simulados con varios manipuladores para solicitudes. Vale. Entonces estoy asumiendo, y eso, estoy asumiendo si la persona que preguntó aquí está aquí y podría aclarar, me encantaría, pero estoy asumiendo que quieres una vez más, escenarios dinámicos, dependiendo de lo que tienes en tu aplicación. Entonces, una vez más, generalmente cuando estás haciendo una solicitud, tu solicitud va a ir a una ruta y esa ruta está definida con MS double. Así que imagina que tienes un escenario que quieres, vas a la API A y esa API va a recibir el parámetro B. Entonces este es un escenario, pero también sabes que tendrás otro contrato especifica que cuando va a la API A con el parámetro C, algo es diferente. Puedes simplemente en tu solicitud y especificar esa ruta específica y probablemente, va a haber diferentes estados también va a ser diferentes rutas también. O puedes ir de la otra manera y simplemente definir eso en tu prueba. Bueno, no entendí tanto esta pregunta, así que di una respuesta un poco vaga respuestas, pero si la persona que te preguntó esto está aquí, por favor ponte en contacto conmigo, o si también estás en línea, ponte en contacto conmigo y lo intentaremos averiguar juntos.

Muy bien. Bueno, eso es todo el tiempo que tenemos para preguntas y respuestas. Entonces Daniel, muchas gracias por unirte a nosotros hoy. Gracias por tenerme. Ahora te toca el fin de semana. Disfruta. Disfruta de Londres.