Despliega con rapidez y confianza utilizando pruebas de contrato y Pact

Bueno, gracias a todos por venir a mi charla sobre cómo implementar con velocidad y confianza utilizando las pruebas de contrato de PACT. Mi nombre es Matt Fellowes. Soy un mantenedor principal de PACT. También soy cofundador de PACTFlow, que es una plataforma de entrega continua de microservicios. Y saben, si no estuviera trabajando en TI, probablemente estaría trabajando en deportes y fitness para alejarme de todo. Si desean contactarme después de esta charla, pueden seguirme en mis redes sociales a continuación.

Entonces, la agenda para hoy, vamos a hablar sobre cómo lanzar software, y en particular sistemas distribuidos. Comenzaremos hablando sobre el problema con las pruebas de integración de extremo a extremo. Luego hablaremos sobre cómo funciona PACT y los principios de las pruebas de contrato. Y luego terminaremos con una demostración.

La forma antigua, o la forma actual en la que muchas empresas prueban sus microservicios, es hacer lo que llamamos pruebas integradas de extremo a extremo. Y lo que eso requiere es que pongas en marcha toda tu plataforma, algo así, y uses una herramienta de prueba de API funcional, como Postman o algo similar, y envíes solicitudes para todo el sistema. Por ejemplo, lo envías a través... tal vez no a través de una interfaz de usuario con Postman, pero lo envías a través de la plataforma, y pasará por todas las capas del sistema. Entonces, Microservicio A, Microservicio B, Microservicio C, y la solicitud pasará por todos los sistemas reales, pasará por redes reales, se comunicará con bases de datos reales, enviará correos electrónicos, lo que sea que tu aplicación real vaya a hacer. Ahora esto es genial, si el sistema funciona y las pruebas pasan, te brinda cierto nivel de confianza de que tu sistema está funcionando como se espera, pero este tipo de pruebas conlleva un costo enorme.

El primer problema es que son lentas, testing para pasar con capas reales y necesitan hacer cosas reales, lo que puede ser lento, por supuesto. Pero también muchas veces no se pueden ejecutar en paralelo, y la razón de eso es la naturaleza estatal de este tipo de interacciones.

El segundo problema con este tipo de testing es que son frágiles y pueden ser no deterministas. Por lo tanto, esta propiedad de inestabilidad está muy presente en este tipo de testing. Incluso si pasan, pueden requerir varias ejecuciones para llegar a ese punto.

Por ejemplo, necesitas que todas las versiones de cada servicio en el sistema estén alineadas. Si alguna de ellas cambia, la prueba podría fallar. Si tienes la versión incorrecta de data, la versión incorrecta de las pruebas o la configuración incorrecta para tu entorno o simplemente alguien ha manipulado el entorno de antemano, es posible que tu prueba falle. Son muy costosas de mantener.

Y cuando encuentras problemas, o cuando tienes un problema, encontrar el problema real y la fuente del problema puede ser realmente costoso de hacer. Por ejemplo, si tienes una falla que está causando el problema en el Microservicio B, bueno, puede que no sea visible desde el exterior por qué esa prueba realmente falló. Es posible que necesites buscar en tus plataformas de registro como Splunk o Simulogic, debas rastrear algunos ID de correlación a través del sistema para descubrir cuál es el problema es. Y luego necesitas encontrar la versión del código para ese servicio en particular, ir al repositorio, y buscar.

Es básicamente como encontrar un problema en producción. Por lo que puede ser bastante costoso encontrar el error en sí mismo. Muchas veces falla solo por esas razones inestables que mencioné anteriormente. Del mismo modo, es difícil lograr una cobertura completa de esta manera. Lo que quiero decir con eso es que tienes múltiples sistemas aquí y tienes muchos escenarios potenciales diferentes que pueden ocurrir. Y al ejecutar tus pruebas de esta manera, es muy posible que no obtengas todas las pruebas que deseas. Porque a, tardan mucho tiempo en ejecutarse. B, son costosas de mantener. Y también simplemente no puedes ejecutar tantas pruebas en el tiempo disponible, porque las combinaciones se vuelven incontrolables.

Debido a que pruebas todo junto de esta manera, bueno, entonces realmente tienes que lanzar todo junto de esta manera. Porque no tienes confianza en que si implemento solo un componente, las cosas seguirán funcionando al final. Así que ahora necesitas implementar las cosas juntas. Y hacer eso significa que los equipos están acoplados entre sí en el momento de la implementación. Y eso significa que los equipos están esperando a que otros equipos terminen sus tareas. Y sabemos por la teoría ágil que eso no es muy bueno. Y este tipo de pruebas no escalan bien. Tienden a empeorar con el tiempo.

Entonces, digamos que aumentas el número de equipos y componentes con el tiempo de esta manera lineal. Lo que ves es esta relación no lineal con el número de entornos o la complejidad de los entornos que necesitas gestionar. Ves que el tiempo de construcción aumenta, o la complejidad de esas construcciones, y el fallo de esas construcciones comienza a aumentar. También ves que el riesgo asociado con el cambio se incrementa exponencialmente. Y, por supuesto, ahora tenemos desarrolladores inactivos, tenemos muchas colas, tenemos, ya sabes, tarjetas en la pared que hacen referencia a otros equipos esperando a que se complete su trabajo antes de que podamos completar el nuestro. Y todo esto tiene un costo enorme asociado.

Por supuesto, las buenas pruebas tienen propiedades completamente opuestas a las que acabamos de mencionar. Son rápidas, están aisladas, son fáciles de entender y fáciles de mantener. ¿Podrían los mocks venir al rescate aquí? Bueno, como probablemente todos hayan escrito, es muy simple escribir dos pruebas unitarias separadas a cada lado del límite del servicio. Podemos escribir una prueba unitaria para el consumidor, simulando al proveedor, y podemos escribir una prueba unitaria para el proveedor, simulando al consumidor. Y estas son geniales. Pueden ejecutarse muy rápido, son fáciles de corregir, fáciles de encontrar errores. Por supuesto, es posible que no representen lo que realmente sucede en producción, por lo que es bastante posible que pongas una suposición que no es válida, y como es una prueba unitaria, no estamos verificando esa suposición más adelante. Y así, tenemos esta buena propiedad, ya sabes, todas estas grandes propiedades, pero el nuevo problema es que en realidad no están representando la realidad. Es difícil mantener ambos lados sincronizados.

Y aquí es donde podemos hablar de los contratos. Probablemente estés familiarizado con el diseño basado en especificaciones, donde un productor de API especifica o crea un contrato utilizando Swagger u otra herramienta, y publica ese documento a todos sus consumidores. Esto tiene muchas propiedades excelentes. Pero uno de los inconvenientes es que cuando mueves, cambias o modificas esa versión del contrato o la especificación, es fácil romper accidentalmente a un consumidor porque no sabes qué partes de la API están utilizando. Requiere mucha diligencia asegurarse de no implementar cambios incompatibles hacia atrás. Aquí es donde podemos hablar de los contratos impulsados por el consumidor, que invierten esa relación. Los consumidores pueden especificar lo que necesitan del proveedor y escribirlo en su propio formato de contrato y dárselo al proveedor, cada consumidor teniendo su propio subconjunto potencial de la API. Luego, la API solo necesita implementar el superconjunto de todos esos contratos, y luego puede hacer su trabajo. Esto tiene algunos efectos secundarios o consecuencias realmente interesantes. El primero es que sabrás cuándo rompes a un consumidor, porque los consumidores te están diciendo qué están usando. Obtiene una forma de documentación, porque los consumidores te están dando exactamente lo que están usando cada vez que envían una compilación, y puedes probar las cosas de forma independiente.

Entonces, aquí es donde entra en juego la herramienta Pact. Combina la idea de mocks aislados y pruebas unitarias rápidas con contratos para garantizar que no haya desviaciones. Es una herramienta de pruebas de contrato impulsada por el consumidor de código abierto y está diseñada para ayudarte a probar tus microservicios y sistemas distribuidos de forma independiente. Sus casos de uso principales son en aplicaciones web JavaScript, aplicaciones móviles nativas que se comunican con servicios RESTful, JSON o XML, o que se comunican a través de colas de mensajes como Kafka o SNS. Sus objetivos son reducir o eliminar por completo la necesidad de pruebas integradas de extremo a extremo y reducir la dependencia de entornos de prueba complicados. Los beneficios de Pact son básicamente que, al tener un enfoque en un solo punto de integración, solo estás observando una cosa a la vez. No necesitas implementar, por lo que no necesitas un entorno de prueba para realizar esta forma de pruebas.

Obtienes una retroalimentación rápida y confiable debido a esto. El error siempre se encontrará en tu máquina. No necesitas buscar en los registros. Esto significa que esas pruebas se ejecutan muy rápido y escalan linealmente. Y por último, debido a que estás probando cosas de forma independiente, ahora puedes lanzarlas de forma independiente.

Ok, hablemos rápidamente de cómo funciona Pact y luego mostraremos cómo funciona en acción. Tenemos un sitio web consumidor... Perdón, tenemos un sitio web que se comunica con una API de productos. Llamamos al sitio web consumidor y a la API proveedor. Y los mensajes que se pasan entre ellos, la suma de esos mensajes, lo llamamos contrato. Es un framework de pruebas de contrato impulsado por el consumidor, por lo que lo primero que haremos es escribir una prueba desde el lado del consumidor para definir las expectativas del proveedor. Lo que hará Pact es simular al proveedor. Nunca los hacemos hablar entre sí. Pero Pact simulará la API del proveedor. Y el consumidor puede decir, dado que hago una solicitud para obtener 1, 2, 3, 4 para el endpoint de producto, espero recibir alguna respuesta. Y hacemos esto para todas las cosas que el consumidor necesita del proveedor. Al final de esa sesión, vamos a registrar esas interacciones en lo que llamamos un archivo Pact o un contrato. Vamos a compartir eso con una herramienta como el Pact broker o Pact flow, que nos ayudará a intercambiar el contrato y versionarlo en todo nuestro ecosistema. Y finalmente, en el lado del proveedor, lo que vamos a hacer es descargar los contratos de Pact flow, los vamos a reproducir en el proveedor. Y ahora Pact va a simular al consumidor. Va a reproducir esta solicitud, verificar las respuestas y si coinciden con lo que el consumidor hace, ahora tenemos simetría en ambos lados de esta interacción. Tenemos dos mocks rápidos y ahora tenemos un contrato que asegura que esos dos mocks son válidos.

Ok. Así que vamos a entrar en nuestra demostración. Vamos a utilizar un sitio web de catálogo de productos React que se comunica con un backend ExpressJS como ejemplo, vamos a probar el endpoint de producto con barra diagonal ID y mostrar cómo los consumidores pueden ayudar a impulsar el diseño de la API. Vamos a ver el flujo de trabajo del proveedor y también cómo podemos controlar los lanzamientos con una herramienta llamada Can I Deploy? Así que veamos la aplicación. Aquí está, es un sitio web muy poco interesante, lo siento, no es el mejor sitio web de React de todos los tiempos. Pero aquí puedes ver, la página de inicio simplemente lista los productos y podemos ver los detalles de un producto individual. Y vamos a acceder a dos endpoints diferentes. Vamos a probar el endpoint de esta página.

De acuerdo. Al observar nuestro código para esto. Vamos a pasar a la prueba del consumidor. Entonces, si miramos aquí en nuestra página de producto, este es nuestro componente React. Puedes ver aquí, para llenar esta página, necesitamos obtener algunos datos de un punto final. Ahora, en lugar de cargar esto de otra manera, vamos a comunicarnos con un punto final de la API y vamos a usar una clase para hacerlo. Entonces, esta clase de API tiene un método llamado obtener producto, y eso es lo que va a obtener los datos del producto para nosotros.

Desde el punto de vista de Pact, podemos probar este método, esto es lo que nos importa, esto es el objetivo de nuestra prueba de Pact, no necesitamos probar nada con React para hacer esta forma de prueba. Y puedes ver aquí, simplemente va a acceder al punto final producto barra diagonal id, va a enviar algunos encabezados y luego va a convertir los datos que regresan en una clase de producto, y la clase de producto se ve así.

En el lado del proveedor, tenemos algo similar, tenemos una definición de producto aquí, tenemos nuestras rutas que manejan los diferentes puntos finales, y también tenemos una prueba de Pact aquí. No vamos a entrar demasiado en la prueba de pacto aquí, porque es mucha configuración, pero básicamente para ejecutar la prueba de Pact en este lado, simplemente vamos a levantar el proveedor, decirle a Pact cómo encontrar los archivos de Pact y los reproduciremos contra el proveedor. Por último, vamos a compartir el contrato con un broker de Pact, en este caso, es un Pact flow publicado. Y nos mostrará el estado actual de la interacción a lo largo del tiempo. Entonces puedes ver aquí que la versión actual del consumidor está en el master, y ha sido implementada en producción y el proveedor también ha sido implementado en producción. Podemos profundizar en el Pacto y ver las diversas interacciones que son compatibles con este contrato. En este caso, al obtener un producto con ID 10, obtenemos el ID, el tipo y el nombre en el cuerpo. Pero lo más importante, lo usaremos para mostrar cómo podemos realizar cambios en el sistema y luego promoverlos a través de los entornos.

De acuerdo, vamos a ver primero la prueba del pacto del consumidor, porque aquí es donde empezamos. Esta es nuestra prueba de pacto aquí. Vamos a seguir el modelo estándar de organizar, actuar y afirmar solo para ver cómo funciona todo esto en conjunto. Así que primero, necesitamos decirle a Pact, necesitamos decirle a nuestra prueba unitaria qué es lo que nuestro código debe hacer. Como dije, Pact es una herramienta de marcado. Va a validar lo que realmente hacemos. Dado que existe un producto con ID 10, al hacer una llamada para obtener ese producto, utilizando el verbo GET en esta ruta. Esperamos recibir un HTTP 200 con algunos encabezados y un cuerpo que se ve como la línea 19. Puedes ver que el producto esperado es ID 10, tipo tarjeta de crédito, nombre 28 grados. El comparador like básicamente dice que no nos importan los valores aquí, solo nos importa que las claves existan y sean del mismo tipo. Así que más adelante, cuando el proveedor verifique esto, no vamos a fallar si se devuelven IDs diferentes o incluso productos diferentes. Tampoco vamos a entrar en los comparadores hoy, pero tenemos una biblioteca flexible que podemos usar para hacer esto mucho más simple.

Lo segundo es llamar realmente a la API. Configuramos nuestro cliente de API y en lugar de comunicarnos con el cliente de producción, vamos a comunicarnos con el servicio simulado de PACKT. Luego, en la línea 42, llamamos al método. Ese método va a llamar a un punto final HTTP real, pero en este caso, va a comunicarse con PACKT en lugar de la cosa real. Y luego, en la línea 45, todo lo que tenemos que hacer es escribir nuestras afirmaciones de prueba unitaria para esta llamada.

Entonces, vamos a fingir que PACKT no existe. Bueno, ¿qué deberíamos probar en esta prueba unitaria para asegurarnos de que nuestro código hizo lo que pensamos que hizo? Esta prueba ya está pasando, como viste antes. Ya se ha publicado en PACKT flow. Lo que queremos hacer es agregar un nuevo campo. ¿Qué sucede cuando evolucionamos esta API? Entonces, este es un sitio web de productos. Sería bueno mostrar un precio para el producto, ¿verdad? Así que agreguemos el precio a la mezcla. Agregaremos esta nueva expectativa en el producto aquí, la agregaremos a nuestra clase de producto también, y luego tendremos el precio disponible para poder mostrarlo en el componente React. Y lo que voy a hacer es crear una nueva rama, mi código, y voy a cerrar esos procesos.

Creemos un nuevo campo, feet, add price. Lo que voy a hacer aquí es simular un proceso de CI como si estuviéramos haciendo una implementación continua. Estamos en una rama, por lo que este será un flujo de solicitud de extracción, y lo que puedo hacer es ejecutar un CI falso. Y lo que esto va a hacer, es ejecutar la prueba, va a publicar el contrato en PACKFLOW. Luego vamos a ejecutar una herramienta llamada ¿Puedo implementar y decir, ¿es seguro lanzar este cambio? Y la respuesta será no, porque este es un nuevo campo, el proveedor nunca ha verificado el contrato, de hecho, el proveedor aún no lo ha implementado. Entonces se nos dirá que aún no es seguro lanzar esto. Así que volviendo a mi terminal, puedes ver que la prueba pasó allí arriba. Hemos publicado los paquetes, y hemos dicho, ¿podemos implementar, y no podemos implementar. Entonces la compilación ha fallado con un código de salida distinto de cero. Puedes ver, sin embargo, en nuestra base de código hay un PACKFLOW que se está creando, y puedes ver que ahora tiene la propiedad de precio capturada en ese archivo de contrato. No vamos a hablar demasiado sobre el archivo de contrato por ahora. Solo sepa que existe, y eso es lo que usamos para mediar todo este proceso. Ahora que hemos agregado la propiedad de precio, echemos un vistazo a PACKFLOW y veamos lo que ve. Genial. Podemos ver que se ha creado un nuevo contrato aquí arriba llamado FeetAddPrice. Aún no se ha verificado. Entonces esta versión del Consumidor no se puede implementar en ningún lugar todavía porque ningún proveedor ha implementado sus características.

Entonces, sigamos adelante y hagamos eso en el proveedor ahora. Ahora tengo algunos cambios en el stash para evitar problemas. Pero lo que vamos a hacer es agregar el precio a la propiedad, la clase Producto y agregarlo también al repositorio, así que hay data.

Entonces, ahí vamos. Podemos ver que se ha agregado el precio. Ahora, en teoría, podemos hacer push a esto en la rama principal. Veamos cómo se ve cuando hacemos commit y push a este cambio. El proveedor debería ejecutar las pruebas descargando los contratos de PacFlow. Compartirá los resultados de esa verificación de vuelta a PacFlow para decir si pasó o tuvo éxito. Luego ejecutará la verificación para determinar si puedo desplegar esta versión del proveedor en producción. La respuesta debería ser sí, porque ya es compatible con la versión actual del consumidor. Y también tiene la nueva funcionalidad para esta nueva rama. Así que lo desplegamos en producción.

De acuerdo, puedes ver que el proveedor se ha ejecutado. Un montón de afirmaciones han ocurrido gracias al framework PAC. Ha publicado los resultados en el broker y ha ejecutado la verificación de si puedo desplegar. La verificación dice que sí. Esta versión del proveedor satisface la versión de producción actual del consumidor al que se desplegará, por lo que se despliega en producción. Si vuelvo a PacFlow y actualizo esta página, verás que esta nueva rama de características ha sido verificada por el proveedor. Y la versión del proveedor que satisface este contrato es la misma que satisface el contrato de producción del consumidor. Por lo tanto, básicamente ahora es seguro fusionar este cambio en la línea principal y hacer push a producción. Así que voy a fingir que he fusionado esto. Vuelvo a la rama principal. Y ejecuto el proceso de CI como si acabara de fusionar esto en la rama principal ahora. Y lo que debería suceder es que ahora el consumidor ejecutará sus pruebas, publicará el contrato. El contrato no ha cambiado. Por lo tanto, cualquier verificación que se haya realizado anteriormente sigue siendo válida. Ejecutará una verificación de si puedo desplegar. Dice, ¿puedo mover este cambio a producción? Y debido a que hay una versión del proveedor que satisface estas necesidades, es seguro hacer eso. Y luego lo desplegamos. Y listo, ahora estamos en producción.

Así que actualicemos esto, la versión de producción del contrato ahora tiene la propiedad de precio, como puedes ver aquí. ¿Qué sucede si eliminamos un campo del proveedor? ¿Qué pasa entonces? ¿Encontraremos un error? Bueno, por ejemplo, si elimino el campo ID, lo siento, voy al proveedor y lo comento, ahora puedo ejecutar NPMT localmente sin realizar ningún cambio y descubrir si voy a romper a alguno de mis consumidores. Ahí lo tienes. Encontró correctamente que un consumidor está utilizando esta propiedad y si la eliminamos, fallaría. Pero si elimino la propiedad de versión, ¿qué va a suceder aquí? Bueno, como sabemos, actualmente no hay consumidores que estén utilizando esta propiedad, por lo que es seguro eliminarla. Ahí vamos. Esa es una propiedad interesante de PACT. PACT es capaz de detectar cambios de esta manera a nivel de atributo para determinar la compatibilidad.

De acuerdo. Hoy hablamos sobre el costo de las pruebas integradas de extremo a extremo. Vimos que tienen un alto costo de mantenimiento y que no escalan bien. Vimos cómo las pruebas de contrato pueden ayudar con las pruebas de integración al combinar los enfoques de pruebas unitarias rápidas y aisladas con contratos para evitar la desviación. Vimos cómo funciona PACT y cómo podemos controlar las versiones usando ¿Puedo implementar?

Espero que esta charla haya sido útil. Agradezco mucho su participación. Si desean hablar más, no duden en ponerse en contacto conmigo en los datos que aparecen allí. Muchas gracias.

Hola Matt. Hola a todos. Gracias por tenerme aquí. ¿Los resultados de la encuesta te sorprenden o lo esperabas? No, eso suena normal. Mira, no todos están sufriendo tanto como para tener que comprar café a granel y comprarse una máquina de café como yo en casa. Pero, ya sabes, la mayoría de las personas encuentran las pruebas de integración, o al menos las pruebas de integración de extremo a extremo testing, lo suficientemente desafiantes como para tener que dedicarles algo de tiempo y generalmente necesitan algo para superar ese dolor, debido a las pruebas inestables, porque lleva tiempo gestionarlas, porque hay que resolver los problemas. Siempre hay una excusa para no querer investigar esas pruebas y escribir esas pruebas y mantener esas pruebas, así que no es del todo sorprendente, pero también es bueno escuchar que no todos están sufriendo tanto como para necesitar, ya sabes, tener cafeína inyectada en sus venas solo para pasar el día.

Sí, pero las pruebas inestables siempre son una buena excusa para tomar otra taza de café.

Hay algunas preguntas. Manuel Zambrano preguntó, ¿podemos usar PacFlow con diferentes tecnologías de consumidores y proveedores? Quiero decir, por ejemplo, un frontend de React y un backend de Python que sirve la API? Esa es una buena pregunta. Probablemente sea la razón principal por la que las personas eligen Pact en lugar de otros marcos alternativos de testing de contratos, por lo que vale la pena mencionar rápidamente Spring Cloud Contract. Entonces, si estás usando Java aquí, porque esta es una conferencia de testing para JavaScript, pero si usas Java, Spring Cloud Contract es una opción decente, está hecho por los chicos de Spring. Tienen soporte para otros lenguajes, pero la forma en que funciona es que aún tienes que escribir scripts groovy, así que técnicamente probablemente sigas escribiendo cosas de JVM. Pero una de las ventajas de Pact es que utiliza una especificación que te permite trabajar en diferentes lenguajes. Desde el principio, los primeros mantenedores reconocieron que esto sería un desafío, que las arquitecturas políglotas eran una realidad y que las pruebas de contrato necesitaban admitir entornos políglotas desde el principio. De hecho, hay una especificación que rige la forma en que se produce la coincidencia de manera independiente del lenguaje. Eso significa que se pueden escribir consumidores diferentes para proveedores diferentes y, de alguna manera, en este entorno, pero la forma en que se produce la coincidencia y la verificación, trasciende los lenguajes. Así que sí, es completamente posible tener un frontend de JavaScript, un frontend de iOS, un frontend de Swift, que se comunica con un backend de Java o un backend de Ruby o un backend de .NET. Puedes combinar y mezclar lenguajes como desees.

Increíble. Steve, probablemente esté pronunciando mal eso. Lo siento.

Me preguntaron qué tan diferentes, slash, relacionadas son las pruebas de contrato en comparación con la aplicación de un esquema JSON a cada solicitud que realizas, por ejemplo, usando Postman? Sí, esa es una excelente pregunta. De hecho, recibimos esa pregunta con frecuencia. Tengo algunos artículos a los que puedo dirigir a las personas después, que hablan sobre la diferencia entre las pruebas de esquema y las pruebas de contrato. Se profundiza un poco más. Una de las primeras cosas con las pruebas de esquema, en primer lugar, es que normalmente solo te enfocas en los cuerpos de las solicitudes. No estás viendo las otras cosas de HTTP, como el verbo, la ruta, la cadena de consulta, las cabeceras, por ejemplo, generalmente no se incluyen en tus pruebas de contrato. También son obviamente una parte muy importante de ese contrato. Pero obviamente, puedes hacerlo. Lo segundo es que incluso si estás usando un esquema JSON en un lado del contrato, ¿qué te garantiza que eso es exactamente lo que el proveedor necesita en el otro lado? Entonces, debes asegurarte de tener una forma de fijar el esquema que utilizas en ambos lados del contrato y garantizar que esos esquemas sean compatibles. Por ejemplo, supongamos que tienes la versión uno del esquema en el lado del consumidor, luego el proveedor actualiza su esquema, debes asegurarte de que esos esquemas estén ahora sincronizados. Entonces, básicamente, puedes hacer eso, pero debes asegurarte de que los esquemas siempre sean los mismos. Y luego, el segundo desafío con eso es si piensas en algo como las pruebas de contrato con PACT, la forma en que quiere funcionar es utilizando tus intermediarios a través de algo como el PACT broker o PACT flow. Y lo que eso hace es permitirte versionar y etiquetar tus contratos, al igual que lo harías con el código Git. Entonces, supongamos que tienes código, ¿verdad? Estás a punto de implementar esto en producción, la versión dos de tu código está en Git, al igual que la versión uno, y necesitas migrar la producción de la versión uno a la versión dos. Entonces, necesitas un proceso para asegurarte de que puedas hacer una transición suave de uno a dos. Y, nuevamente, si vas a usar tu propia herramienta de pruebas de esquema, deberás crear tu propio proceso para evolucionar ese esquema de la versión uno a la versión dos. Cuando tienes múltiples componentes en el sistema. Nuevamente, no es que no puedas hacer eso. Pero deberás construir muchas cosas que los marcos de pruebas de contrato ya tienen incorporadas. Lo que diré, sin embargo, es que es una estrategia que parece estar empleando y, ya sabes, probablemente puedas llegar al 70% del camino y eso podría ser suficiente para la mayoría de los casos de uso de las personas.

Muchas gracias por esta respuesta detallada. Richard Fordshow pregunta: ¿Las pruebas de contrato son principalmente para pruebas unitarias o para pruebas de extremo a extremo, como con Cypress? Supongo que la pregunta se refiere a dónde se ubicarían las pruebas de contrato en la pirámide de pruebas. Sí, es una buena pregunta. Probablemente haya dos preguntas. Una es dónde encaja en la pirámide. ¿Puedes usar herramientas como herramientas de pruebas de extremo a extremo, que creo que es, creo que como comunidad, necesitamos solucionar eso, las pruebas de extremo a extremo significan demasiadas cosas? Tenemos que solucionar eso. No podemos tener una situación en la que Cypress signifique prueba de extremo a extremo y realmente solo esté probando la capa de interfaz de usuario. Y también podemos referirnos a las pruebas de extremo a extremo que pasan por toda la plataforma. Así que lanzo ese desafío para que alguien intente solucionarlo. Pero hablemos de la primera pregunta. En cuanto a dónde encajan las pruebas de contrato en la pirámide, encajan en dos lugares en el lado del consumidor. Perdón, es mucho más parecido a una prueba unitaria. Básicamente, debes elegir una sola función como viste en la charla y ejecutar una prueba unitaria para esa función. Por lo general, eso es bastante sencillo. En el lado del proveedor, tienes algunas opciones más sobre qué tan arriba y abajo de la pirámide puedes ir. Por lo general, se encuentra en el medio. Normalmente superponemos la prueba de contrato en el medio de esa pirámide, la prueba de servicio o la capa de prueba de integración, donde básicamente ejecutarías tu proveedor como una caja negra, iniciarías cualquier dependencia de terceros y comenzarías el servicio y luego PACT hablaría con ese servicio, a través de mecanismos HTTP, pasando probablemente por múltiples capas de tu aplicación, pero por lo general aún se ejecutan muy rápidamente. Son más parecidos a una prueba unitaria, pero no son realmente una prueba unitaria, porque tienen que pasar por algunas capas. Eso es generalmente donde encajan en la pirámide. Además de eso, lo que normalmente hacemos es complementar, para eliminar las pruebas de extremo a extremo, complementamos esas pruebas de contrato. O si lo piensas, tenemos que deshacernos de las pruebas de integración de extremo a extremo. Las pruebas de contrato eliminan las pruebas de las pruebas de extremo a extremo que tienen las pruebas para la colaboración y la comunicación. ¿Pueden comunicarse entre sí? Todos los aspectos del contrato desaparecen. Por lo tanto, reducimos un poco las pruebas de extremo a extremo. Luego, miramos allí y decimos, bueno, en realidad, generalmente lo que encuentras es que en las pruebas de extremo a extremo, muchas de ellas son en realidad el consumidor que no confía en el proveedor. Entonces, lo que haces es sacar esas pruebas y decir, no, no deberían estar ahí. Deben estar en la base de código del proveedor. Su trabajo es asegurarse de que su código funcione, no es trabajo del consumidor. Luego, lo reducimos a solo unas pocas pruebas y es entonces cuando podemos preguntarnos, ¿cuál es el valor de tener estas pocas pruebas restantes? Tal vez podamos ponerlas en pruebas sintéticas de producción o en otro lugar.

O podemos eliminarlos por completo porque no están agregando valor y podemos avanzar más rápido. Ahora, la segunda parte de esa pregunta creo que se refiere a si se puede integrar con algo como Cypress. La respuesta corta es sí, se puede integrar con Cypress. Hay algunos desafíos al hacer esto y actualmente estamos trabajando para que sea menos problemático hacerlo para las pruebas con Cypress. Pero en resumen, porque típicamente con las pruebas de Cypress, vas a tener mucha superposición. Realmente no quieres capturar demasiados escenarios superpuestos en tus pruebas de contrato porque deben reproducirse contra el proveedor. Y eso puede convertirse en una carga para el proveedor si agregas demasiados. Pero nuevamente, estamos trabajando para optimizar ese proceso y hacer que sea más fácil usar Cypress para escribir pruebas y verificar el lado del proveedor. Y debo mencionar que, literalmente, en PackFlow, ahora estamos escribiendo pruebas usando Cypress para algunas de nuestras interfaces de usuario y también estamos experimentando con generar contratos a través de eso. Y sospecho que en los próximos meses probablemente lanzaremos un complemento para Cypress como ejemplo que se podría replicar para otros. De acuerdo, genial. Así que creo que tenemos tiempo para una pregunta más y Auto Gibbon pregunta, ¿cómo puedo, cómo se puede integrar el flujo de trabajo de implementación en suites de entrega continua? ¿Hay una respuesta corta para esta pregunta? Si la respuesta es más larga, tal vez podamos llevarla a la sala de oradores. Lamento interrumpirte. La respuesta corta. Sí, es bastante común. Es muy simple. Tenemos algunas herramientas de línea de comandos que puedes usar y generalmente es solo cuestión de agregar la herramienta de línea de comandos en ese paso donde quieras poner ese paso. Y como viste, simplemente tomando la versión de la pieza de software actual, el entorno al que deseas implementar y simplemente realizar esa llamada y devolverá un código de salida de cero o uno, cero significa éxito, uno significa fallo, y eso es todo. Y eso es generalmente lo que harás. Un código de salida distinto de cero debería cancelar tu canalización. De acuerdo, impresionante. Así que hubo algunas preguntas más. Y Matt se dirigirá a la sala de oradores en un horario especial. Así que si hay preguntas sin respuesta, asegúrate de unirte. Y Matt, nuevamente, muchas gracias por unirte hoy. Fue un placer tenerte aquí. Sí. Gracias. Gracias a todos por acompañarme, Anna.