Más allá de REST - Pruebas de contrato en la era de gRPC, Kafka y GraphQL

Rate this content
Bookmark

Las arquitecturas distribuidas modernas son más complejas que nunca, con la mayoría de las empresas operando en múltiples lenguajes, protocolos y estilos arquitectónicos. Esto plantea desafíos significativos para los equipos de ingeniería que cada vez más se les pide entregar más rápidamente. Si bien la práctica de las pruebas de contrato se hizo prominente durante el auge de los microservicios RESTful para abordar desafíos similares, la declaración del problema ha evolucionado. En esta charla, discutiremos estos nuevos desafíos y demostraremos cómo las pruebas de contrato siguen siendo tan relevantes como siempre para ayudar a resolverlos.

22 min
03 Nov, 2022

Video Summary and Transcription

Esta charla explora los desafíos de la comunicación de API en un entorno multi-protocolo y las limitaciones de REST. Se discute cómo las pruebas de contrato pueden abordar estos desafíos al centrarse en la comunicación de API y reducir la dependencia de las pruebas de extremo a extremo. La charla también examina las limitaciones de especificaciones como OpenAPI y JSON schema y los desafíos de la evolución y versionado de los puntos finales. Se destacan los beneficios de las pruebas de contrato impulsadas por el consumidor para garantizar la compatibilidad de la API y se proporciona una descripción general del marco PACT como solución estandarizada.

Available in English

1. Introducción a Más allá de REST y Pruebas de Contrato

Short description:

Gracias por unirse a mi charla sobre Más allá de REST, pruebas de contrato en la era de gRPC, Kafka y GraphQL. Hoy examinaremos si REST es el problema y si existen tecnologías superiores para la comunicación de API. Exploraremos diferentes clases de tecnologías, como OAS, ASIN KPI, GraphQL y IDL como Protobufs y Avroans. Utilizando PACT como una implementación concreta, entenderemos cómo las pruebas de contrato se ajustan a estas tecnologías. Comprendamos por qué existen las pruebas de contrato y el contexto en el que operan. La investigación muestra que los microservicios internos son un enfoque importante para los equipos.

OK, bueno, gracias a todos por venir a mi charla sobre Más allá de REST, pruebas de testing en la era de gRPC, Kafka y GraphQL. Mi nombre es Matt Fellowes. Soy Gerente de Producto Principal en SmartBear. Fui cofundador de Pactflow, que se unió a la familia SmartBear en abril de este año. Y soy un mantenedor principal de PACT, que es un marco de pruebas de contrato impulsado por el consumidor, uno de código abierto. Y el tema, o el curso, hasta gran parte de la charla de hoy.

Antes de trabajar en Pactflow, fui consultor. Soy un consultor en recuperación, y tuve la suerte de trabajar en algunas de las organizaciones más grandes y conocidas de Australia y sus sistemas distribuidos, y realmente los vi evolucionar a lo largo de mi career. Ha habido, por supuesto, una gran cantidad de cambios tecnológicos desde los días en que SOAP, que era la tecnología predominante cuando me uní a la industria, hasta los años. Y en mi career relativamente corta, he trabajado desde ese punto de partida de SOA, SOAP hasta REST y microservicios, el auge de la nube pública y el IOT, el event sourcing, la estructura de eventos, las canalizaciones de datos modernas y, por supuesto, las arquitecturas sin servidor. Y descubrí que en muchas de estas situaciones y contextos, las pruebas de contrato eran aún muy relevantes y a menudo buscaba introducir pruebas de contrato en lugares donde había beneficios en el desplazamiento hacia la izquierda, avanzar más rápido y resolver esos problemas en sí mismos. Pero, por supuesto, durante esas implementaciones o a menudo, yo sería el destinatario de algún comentario sarcástico, generalmente de otra consultoría competidora, que tenía el siguiente argumento en forma de shape. Si simplemente usáramos la tecnología en blanco, entonces no necesitaríamos pruebas de contrato. Pero ¿es cierto? Bueno, hoy vamos a examinar esa afirmación. Vamos a hacer la pregunta ¿REST es realmente el problema? ¿Y podríamos ahorrarnos la molestia de tener que pensar en las pruebas de contrato, ejecutar pruebas utilizando una tecnología superior para la comunicación de API? Vamos a aprender brevemente qué son las pruebas de contrato, por qué existen y el problema que resuelven. Y vamos a ver, ya sabes, si la historia se repite o si estas nuevas tecnologías y tendencias arquitectónicas realmente resuelven el problema. Específicamente, vamos a ver algunas clases de tecnologías. Vamos a ver especificaciones como OAS y ASIN KPI hasta cierto punto, GraphQL y también IDL y cosas como Protobufs y Avroans, Rift. Por supuesto, hay otros, pero estos son, con mucho, las alternativas más comunes que me sugieren mis interlocutores consultores. Los veremos desde una perspectiva general de pruebas de contrato, pero por supuesto utilizaremos PACT, que obviamente es una herramienta en la que trabajo, como una implementación concreta para ayudarnos a comprender y cómo funciona en la práctica. Y espero que veas que, ya sabes, si bien PACT ha evolucionado para satisfacer algunas de estas necesidades, también veremos que el problema y la solución son mucho más generales que cualquier tecnología o lenguaje específico que hayamos discutido hoy.

Permítanos hablar rápidamente o comprender por qué existen las pruebas de contrato y el contexto en el que operan. Creo que comenzar con una cita de un cliente es una buena manera de ambientar la escena, solo para ayudarnos, ya sabes, a sentir el problema. Esta es una cita de un prospecto de PACT flow que busca ayuda y, por el bien del argumento y para proteger al inocente, llamémoslo Bill. Y Bill es líder de una organización de pruebas para más de 40 equipos en una institución bancaria muy grande. Y aquí puedes ver que básicamente describe cómo trabaja en este entorno grande con un entorno de pruebas altamente volátil, lo que lo hace desafiante, y está tratando de descubrir cómo puede usar pruebas de contrato para probar todas las cosas que tiene. Tiene servicios RESTful, GraphQL, Kafka, sistemas de terceros, todas estas cosas, ¿verdad? Lo que puedes deducir de esto es que trabaja en este entorno caótico, es complejo y está buscando formas de llevar algo de proceso y control a esa situación. Ahora, si suena algo parecido a su empresa o arquitectura, no está solo. La investigación del estado de calidad de SmartBear, así como el informe de API de Postman, realmente respaldan esto. Y podemos ver que, en primer lugar, los microservicios internos se están convirtiendo en un enfoque masivo para los equipos.

2. Desafíos y Soluciones para las Pruebas de Microservicios

Short description:

Puedes ver que la mayoría de las empresas operan en un entorno de múltiples protocolos y muchas enfrentan desafíos con la velocidad de entrega, la complejidad de los sistemas y la escalabilidad de su ecosistema. Las organizaciones maduras se ven particularmente afectadas por estos problemas. El enfoque tradicional de pruebas integradas de extremo a extremo para microservicios puede ser lento, inestable y difícil de depurar. Sin embargo, las pruebas de contrato ofrecen una solución al reducir la dependencia de las pruebas de extremo a extremo y centrarse en las comunicaciones de la API. Al simular las dependencias y validar las simulaciones, las pruebas de contrato garantizan que los sistemas puedan comunicarse de manera efectiva.

Aquí puedes ver que el 61% dijo que verán el mayor crecimiento para los microservicios. Pero en realidad, detrás de escena, leerás que en realidad hay servicios internos que hacen que los datos estén disponibles internamente para otros equipos para crear más valor, lo cual es realmente interesante. Pero también puedes ver que la mayoría de las empresas operan en un entorno de múltiples protocolos, alrededor del 81% o así, y casi el 60% tiene tres o más protocolos.

Ahora, por supuesto, aunque los microservicios no son nuevos y se han aprendido muchas lecciones, hay estos problemas que estamos empezando a ver, ya sabes, realmente una década después de que hayamos adoptado esta nueva forma de hacer las cosas. En el informe, o en ambos informes, podemos ver que el 50% de las personas afirmaron que la experiencia o las habilidades eran una barrera para implementar los microservicios, y el 35% afirmó que la complejidad de los sistemas, este es el segundo problema, se está convirtiendo en un problema. Y los obstáculos están relacionados con la velocidad de entrega, o la velocidad de entrega esperada, en comparación con el tiempo real para probar y construir cosas, lo cual es realmente contradictorio. Y lo que encontré más interesante de todo es que las organizaciones maduras son las que sienten el dolor. Y entonces piensas, ¿por qué es contraintuitivo? Si son maduros, probablemente tengan todas estas prácticas y tecnología y demás para lidiar con ello, pero creo que las razones son bien comprendidas.

La primera razón, o una de esas razones, es cómo probamos los microservicios hoy en día. La mayoría de las empresas confían en pruebas y sistemas distribuidos utilizando una forma de pruebas de integración de extremo a extremo. Esto implica básicamente tomar todas tus aplicaciones y desplegarlas en un gran entorno compartido y luego ejecutar una serie de pruebas en todo el sistema, en todas las capas de tu sistema, ¿verdad? Y luego, si eso funciona, puedes implementar. Ahora, esto puede darte un alto grado de confianza. Si pasan, tienden a ser bastante lentas, y también tienden a ser muy inestables y difíciles de depurar. Y debido a todo esto, te brindan retroalimentación mucho más adelante en el ciclo de vida, ¿verdad? Porque has tenido que implementarlos antes de poder obtener esa retroalimentación. También significa que son muy difíciles de implementar. Probablemente no puedas implementar cosas de forma independiente y probablemente tengas un monolito distribuido en lugar de un conjunto coherente de componentes cooperativos que trabajan hacia un objetivo único en mente.

Esto crea un problema cuando comienzas a escalar el tamaño de tu ecosistema, tanto las personas como el software. A medida que haces esto, al agregar nuevos componentes y personas al sistema, ves esta respuesta no lineal a cosas como el costo, la complejidad, el tiempo o el número de entornos, el tiempo de construcción, el costo asociado con el cambio y el tiempo de inactividad del desarrollador. Pero si miras con mucho cuidado, te darás cuenta de que realmente comienzas a sentir el dolor un poco más adelante. Ese punto de inflexión no está al principio, así que entras al sistema pensando que es fácil de usar, pero luego, a medida que escalas, eventualmente llegas a este punto de inflexión donde se vuelve realmente doloroso. Y así no es de extrañar que Bill esté pasando un mal momento. Esto explica un poco lo que está sucediendo allí.

De acuerdo, ¿cuál es la solución? Bueno, una de las soluciones es utilizar cosas como las pruebas de contrato. Las pruebas de contrato pueden ayudar al reducir muchas de las pruebas de extremo a extremo y reemplazarlas por una forma de probar las comunicaciones de tu API, que es a menudo lo que las pruebas de extremo a extremo buscan hacer. Las pruebas de contrato son una técnica para garantizar que dos sistemas puedan comunicarse. Y examinamos esos puntos de integración y lo hacemos simulando las dependencias. Entonces, si eres un consumidor de la API, simulas el proveedor y reproduces esas simulaciones contra él más tarde en la vida real contra el proveedor real. Y si esas simulaciones han sido validadas, tenemos confianza en que estos dos sistemas pueden comunicarse. Y el beneficio de esta forma de trabajar es que es mucho más fácil de entender. Solo estás probando un punto de integración a la vez.

3. Introducción a REST y otras especificaciones

Short description:

No necesitas entornos de prueba dedicados, puedes ejecutarlo en tu máquina de desarrollo. Estas pruebas se escalan de forma lineal y podemos implementar los servicios de forma independiente. Ahora volvamos al argumento original de mi consultor, Interlocutor, y hagamos la pregunta, ¿es REST realmente el problema? ¿Y podríamos ahorrarnos todos los problemas usando algo diferente? Comencemos con OpenAPI y su contraparte, JSON schema. Pero también puedes pensar en esto aplicando a cosas como AsyncAPI y SOAP y otras especificaciones.

No necesitas entornos de prueba dedicados, puedes ejecutarlo en tu máquina de desarrollo. Esto te brinda una retroalimentación rápida y confiable que es fácil de depurar. Estas pruebas se escalan de forma lineal y podemos implementar los servicios de forma independiente. Y, por supuesto, podemos rastrear esto a lo largo del tiempo, lo que nos da la capacidad de evolucionarlos. Hablamos de esto en la Cumbre TestJS anterior. Vuelve y mira ese video si quieres conocer el resto de los detalles de esa charla.

Ok, con suerte ahora tenemos una idea del problema con el que estamos tratando y cómo las pruebas de contrato podrían ayudar con eso. Ahora volvamos al argumento original de mi consultor, Interlocutor, y hagamos la pregunta, ¿es REST realmente el problema? ¿Y podríamos ahorrarnos todos los problemas usando algo diferente? Comencemos con OpenAPI y su contraparte, JSON schema. Pero también puedes pensar en esto aplicando a cosas como AsyncAPI y SOAP y otras especificaciones. En cierta medida, GraphQL también entra en esta mezcla. No tenemos tiempo para hablar específicamente de GraphQL hoy.

4. Resolviendo problemas con especificaciones

Short description:

Las especificaciones contienen todos los elementos necesarios para comunicar lo que puede hacer una API. JSON schema ayuda a definir la estructura de los datos, pero tiene limitaciones. Una API no es incompatible con una especificación, ya que la especificación es abstracta y no siempre clara. Los campos opcionales y nulos en los documentos de OpenAPI pueden dificultar la comprensión de los datos disponibles. Los puntos finales polimórficos complican aún más el panorama.

Entonces, ¿cómo pretende resolver un problema? Bueno, lo primero es que las especificaciones contienen todos los elementos necesarios para que los humanos y puedan comunicar lo que puede hacer una API. Y utiliza cosas como JSON schema para decirnos cuál es la estructura de los datos entrantes y cómo debería ser la forma de la respuesta. O lo que también puede ser. Y luego podemos generar clientes y servidores de API a partir de eso OAS.

Entonces sabemos que no vamos a romper ningún cambio. ¿Verdad? Entonces, si podemos generar un código de cliente a partir del OAS, ¿no estamos siempre garantizados de tener un sistema funcional? Bueno, por supuesto que la respuesta es no. De lo contrario, no estaríamos aquí. Y si eres lo suficientemente mayor como para recordar SOAP, recordarás que también teníamos todas estas cosas en características. Una especificación clara, un esquema claro y generación de clientes y generación de esquemas y servicios. Pero no resolvió el problema. Y REST obviamente tiene algunos principios de redundancia mejorados incorporados en el diseño de él. Ya sabes, la ley de Postel y la extensibilidad. Pero en realidad no es suficiente.

Y si estás mirando aquí, si miras esta cita, esto es del sitio web de JSON schema. Básicamente dice que si vas a hacer este tipo de pruebas con JSON schema para validar tu solicitud, necesitarás dos tipos de validaciones. Uno es una herramienta estructural, a nivel de esquema, que es lo que JSON schema puede hacer. Y otro a nivel semántico. Y eso debe hacerse en código, probablemente. Así que JSON schema aún no puede hacer eso. Incluso te lo dice.

Entonces, el aforismo de que una API no es incompatible con una especificación comienza a resumir cómo pienso acerca de y cómo pensamos acerca de las API abiertas. Lo que quiero decir con eso es que el esquema es en realidad abstracto. Y por lo tanto, es muy difícil decir que una API realmente implementa una especificación porque una especificación es en realidad abstracta y no exactamente clara. Ejemplos. Entonces, campos opcionales y nulos. En documentos de OpenAPI suficientemente avanzados, verás el uso de campos opcionales y nulos pero no sabrás en qué situaciones esos campos estarán o no presentes. Entonces, en algunos casos, muchos de esos campos resultaron ser opcionales. Y ahora es realmente difícil entender qué datos estarán disponibles en qué momento. Pero ciertos consumidores pueden necesitar esa información. Combina esto con puntos finales polimórficos.

5. Desafíos con los puntos finales y la evolución

Short description:

Los puntos finales que aceptan diferentes entradas y salidas crean desafíos para determinar la correspondencia entre ellos. SOAP tenía Schemetron para protección, pero requería XSLT y funciones. Los SDK generados por el cliente dificultan saber cómo los consumidores utilizan la interfaz, lo que requiere un mecanismo de evolución diferente, a menudo la versionización.

Entonces, estos son puntos finales que pueden aceptar entradas de diferentes formas y salidas de diferentes formas. Ahora se vuelve muy difícil decir para cada recurso en su documento, qué entrada corresponderá a qué salida y bajo qué condiciones. En el caso de SOAP, en realidad teníamos Schemetron para ayudarnos con esto. Tenía esta capa adicional de protección que se podía colocar encima de él, pero necesitaba XSLT para hacerlo, que utilizaba funciones para lograrlo. Por supuesto, también perdemos de vista el área de servicio de la API. Entonces, si estamos utilizando SDK generados por el cliente, bueno, no sabemos qué está haciendo nuestro consumidor, así que tenemos que asumir que están utilizando toda la interfaz. Lo que significa que necesitamos un mecanismo de evolución diferente. El estándar aquí va a ser la versionización, de la cual hablaremos en un momento.

6. Desafíos con los SDK de cliente y la versionización

Short description:

Los SDK de cliente pueden modificarse y utilizarse de formas inesperadas, lo que lleva a la desviación. La versionización es una práctica común pero dolorosa que requiere construir, mantener, probar y lanzar múltiples versiones de software. El costo de mantener el código suele ser mayor que construirlo. Evitar esta sobrecarga es deseable.

Por último, pero no menos importante, los SDK de cliente pueden modificarse y utilizarse de formas inesperadas. Estaba hablando con uno de nuestros ingenieros de soluciones en Europa que trabaja con algunos de los clientes más grandes de Smagger y Smagger Hub en el mundo. Mencionó que básicamente el 90% de todos los clientes que utilizan CodeGen realmente modifican el código generado cuando el sistema operativo cambia después de esa generación inicial. Esa oportunidad de desviación definitivamente sigue presente.

Por supuesto, toquemos brevemente el tema de la versionización. La versionización es la práctica más común aquí, pero es dolorosa. No queremos hacerlo si podemos evitarlo. Los equipos necesitan construir otra versión del software, mantenerlo, probarlo, lanzarlo. Ahora tenemos múltiples versiones que debemos mantener, por lo que tenemos más código para mantener, por supuesto. El costo de mantener el código suele ser mucho mayor a lo largo del ciclo de vida que construirlo. Suponiendo que no sabemos qué están utilizando nuestros consumidores, la funcionalidad siempre se mantiene a través de esas versiones porque tenemos que asumir que la necesitan y la quieren. Y luego necesitamos llevar a los consumidores eventualmente a esas nuevas versiones, lo que nos requiere nuevamente monitorear, coordinar y comunicar a las personas sobre esas versiones. Realmente, este es el costo y si podemos evitar esta sobrecarga, deberíamos hacerlo.

7. Interface Definition Languages and Understanding

Short description:

Hablemos sobre los lenguajes de definición de interfaz como Protobufs, Avro y Thrift. A menudo se sugiere el uso de Protobufs como solución para evitar las pruebas de contrato debido a su capacidad de evolución de esquemas incorporada. Sin embargo, la sintaxis y la semántica son diferentes, y el hecho de que podamos comunicarnos no significa que nos entendamos.

Entonces hablemos sobre la segunda clase de problemas aquí. Vamos a hablar sobre los lenguajes de definición de interfaz. Estamos hablando de cosas como Protobufs, Avro y Thrift, y debo decir que de todos ellos, Protobufs es el comentario más común que me han hecho, diciendo que podríamos simplemente usar Protobufs y no necesitaríamos pruebas de contrato porque tiene una evolución de esquemas incorporada desde el principio. De hecho, es tan bueno que puedes avanzar y retroceder en el tiempo. Puedes usar clientes antiguos con servidores más nuevos y clientes más nuevos con servidores más antiguos y todos pueden comunicarse mágicamente. Y, por supuesto, también admite la generación de código. Por lo tanto, podemos crear servidores y clientes a partir de esas definiciones. Entonces, si eso es cierto, ¿por qué Protobufs y gRPC son la característica más solicitada en nuestra hoja de ruta de código abierto? Bueno, la respuesta aquí es que las ideas verdes sin color duermen furiosamente. ¿Qué estoy diciendo aquí? Obviamente, esta es una afirmación absurda. En realidad, proviene de un hombre llamado Noam Chomsky, quien escribió sobre esto en la década de 1950 en su tesis sobre el lenguaje. Y estaba hablando sobre lo que está haciendo aquí es sobre la sintaxis y la semántica, que la conformidad sintáctica no significa que sea comprensible semánticamente. La gramática y la sintaxis son diferentes. No hay significado aquí. Entonces, lo que estamos tratando de decir es que, aunque podamos comunicarnos entre nosotros, aún debemos entender mejor lo que estamos diciendo.

8. Desafíos con Protobufs y Campos Opcionales

Short description:

Consideremos un ejemplo con una cola de Kafka y un consumidor que lee pedidos. Si cambiamos la estructura del pedido, el consumidor aún necesita el valor total. Los campos opcionales pueden crear errores, como se ve en un caso con gRPC y Protobufs. La versión tres de Protobufs elimina los campos requeridos, lo que hace que la API sea incomprensible. Gestionar cambios disruptivos y la seguridad del transporte en Protobufs puede ser desafiante debido a los sistemas de tipos limitados.

Veamos un ejemplo aquí. Supongamos que tenemos una cola de Kafka, un tema donde publicamos pedidos que se están completando en ese tema. Y tenemos un consumidor en ese tema que lee todos los pedidos que llegan y calcula los totales, solo para hacer un informe o algo así, ¿verdad? Entonces, va a encontrar todos estos pedidos, cada vez que llega uno, mira el total, lee el valor total y lo imprime o lo guarda en algún lugar.

Ahora, supongamos que necesitamos cambiar esa estructura de pedido. Tal vez necesitamos dividir el total en diferentes valores. Tal vez solo dividirlo en GST o impuestos o lo que sea, o necesitamos moverlo a algún lugar más en la carga útil, ¿verdad? De cualquier manera, ha cambiado. Y ahora, hemos enviado este nuevo mensaje. Bueno, solo porque el consumidor puede leer el mensaje no significa que no necesitara ese valor total, ¿verdad? Todavía necesita el valor. De lo contrario, no puede hacer su trabajo.

Este problema se manifiesta aún más y se vuelve mucho más difícil cuando se combina con campos opcionales. En la investigación de esta charla, hablé con un equipo que trabajaba con gRPC y Protobufs en una empresa global de procesamiento de pagos. Y fue un error extraño que apareció cuando los comerciantes ocasionalmente no recibían pagos del proveedor. Y después de un análisis y depuración cuidadosos, descubrieron que había este nuevo servicio de comerciantes que se había cambiado ya que una API de configuración tenía un nuevo campo booleano para habilitar el guardado de pagos para un comerciante. Y descubrieron que había un solo cliente que no conocía esta actualización. Y cada vez que enviaba una solicitud al servicio de comerciantes, inadvertidamente deshabilitaba los pagos del comerciante porque el campo predeterminado, por supuesto, iba a ser falso. Así que puedes ver cómo este tipo de error puede ser particularmente malicioso de encontrar y resolver. Y en realidad, es un caso en el que probablemente no quieras la compatibilidad hacia adelante y hacia atrás. Tal vez una explosión de red sería mejor. Y de hecho, para empeorar las cosas, la versión tres de Protobufs elimina por completo los campos requeridos , lo cual se parece mucho a lo que sucedió con SOAP en los viejos tiempos, donde todo era un campo opcional y realmente era una API incomprensible. Así que volviendo a los desafíos con Protobufs, hablamos sobre la semántica y los campos opcionales. Aún necesitamos gestionar cambios disruptivos. Los descriptores de campo y cosas como estas, técnicamente o teóricamente, deberían ser fáciles de gestionar, pero en realidad, en la práctica, es muy fácil refactorizar accidentalmente tu código y cambiar los descriptores de campo. Es posible que debamos considerar cómo gestionamos la seguridad del transporte en el caso de Protobufs, que puede utilizar diferentes tipos de transporte. Es posible que deseemos reducir los tipos. Los Lenguajes de Definición de Interfaz (IDL), muchas de estas tecnologías, de hecho, no tienen sistemas de tipos realmente completos. GraphQL es un buen ejemplo, lo tiene. Pero digamos que quieres almacenar una fecha, una fecha semántica o un formato particular de una fecha, o un SIMVIR, todas estas cosas. Bueno, el lenguaje no tiene esos primitivos incorporados. Necesitas agregarlos encima. Eso es en realidad un desafío.

9. Consumer-Driven Contract Testing and API Evolution

Short description:

En realidad, podría ser un problema. Y, por supuesto, si usamos SDK y demás, perderemos visibilidad como antes en el uso real del cliente. Volvamos a las lecciones que podemos aprender de todo esto y veamos si podemos entender por qué las pruebas de contrato impulsadas por el consumidor son tan efectivas para ayudarnos. Su contrato de proveedor no es su API. Es solo una representación de su API. Usamos grabación y reproducción para probar los ejemplos representativos contra el proveedor real. Esto nos da confianza de que realmente funcionará porque lo estamos probando. También obtenemos especificaciones mediante ejemplos para esto porque eso es lo que estamos haciendo. Y eso reduce la ambigüedad. En realidad, podemos viajar en el tiempo en esa evolución del servicio porque ahora conocemos las versiones de la aplicación y los contratos válidos entre ellas en cualquier momento. Podemos verificar si esta versión del consumidor puede leer mensajes de este productor y viceversa. Codificamos esas preocupaciones de transporte en el contrato. Podemos hacer una coincidencia de tipos estrecha en el contrato. Y porque tenemos todos los contratos, sabemos lo que están haciendo todos nuestros consumidores. Tenemos el área de superficie que nos brinda un mecanismo para evolucionar sin tener que hacer versiones. Las pruebas de contrato proporcionan este intercambio de datos generalizado que funciona en diferentes protocolos, transportes y tipos de contenido.

En realidad, podría ser un problema. Y, por supuesto, si usamos SDK y demás, perderemos visibilidad como antes en el uso real del cliente. Y, por supuesto, si aceptamos estos problemas, ahora necesitamos una nueva forma de coordinar los cambios.

De acuerdo. Espero que hayas comenzado a ver un poco de un tema aquí. Y, obviamente, estas tecnologías nos brindan algunos beneficios que en realidad no resuelven este problema del que hemos estado hablando.

Entonces, volvamos a las lecciones que podemos aprender de todo esto y veamos si podemos entender por qué las pruebas de contrato impulsadas por el consumidor son tan efectivas para ayudarnos. El primer punto que quiero hacer es que su contrato de proveedor no es su API. Es solo una representación de su API. De hecho, cualquier cambio observable en el comportamiento y la API será considerado como un cambio rompedor por ciertos consumidores. Esta observación se conoce como la Ley de Hiram. Pero aunque no podemos hacer que esta ley desaparezca, podemos encontrar formas de reducir la ambigüedad. Y una de esas formas es incorporar la perspectiva del consumidor en la imagen, que es, por supuesto, cómo las pruebas de contrato y PACT pueden ayudarnos.

Usamos grabación y reproducción para probar los ejemplos representativos contra el proveedor real. Esto nos da confianza de que realmente funcionará, porque lo estamos probando. También obtenemos especificaciones mediante ejemplos para esto, porque eso es lo que estamos haciendo. Y eso reduce la ambigüedad. Ahora podemos ver cómo se supone que debe funcionar. Mejora la comprensión de la API. En realidad, podemos viajar en el tiempo en esa evolución del servicio, porque ahora conocemos las versiones de la aplicación y los contratos válidos entre ellas en cualquier momento. Así que podemos avanzar y retroceder en el tiempo. Podemos verificar si esta versión del consumidor puede leer mensajes de este productor y viceversa. Muy interesante. Codificamos esas preocupaciones de transporte en el contrato. Podemos hacer una coincidencia de tipos estrecha en el contrato. Y, por supuesto, porque tenemos todos los contratos, sabemos lo que están haciendo todos nuestros consumidores. Tenemos el área de superficie que nos brinda un mecanismo para evolucionar sin tener que hacer versiones.

Así que espero que puedas ver que las pruebas de contrato proporcionan este intercambio de datos generalizado que funciona en diferentes protocolos, transportes y tipos de contenido. Ya sea que estemos proporcionando APIs Restful a través de HTTP o protobufs a través de gRPC o Kafka, o ejecutando Avro en un sistema de archivos como parte de un pipeline de ETL de datos, el problema que estamos tratando de resolver es realmente el mismo. ¿Podemos comunicar datos entre múltiples versiones de aplicaciones en evolución? Si bien PACT no tiene soporte nativo para todas estas tecnologías de forma predeterminada, se puede ampliar mediante complementos.

10. Conclusion and Call to Action

Short description:

Puedes escribir un complemento en el lenguaje que elijas para admitir transportes, protocolos y reglas de coincidencia. PACT ahora admite varios lenguajes y ha lanzado soporte beta para JS. La falta de estandarización para el diseño y las pruebas contribuye a los desafíos de las microservicios. Las pruebas de contrato reducen la complejidad y ambigüedad en las especificaciones de la API. PACT proporciona un flujo de trabajo estandarizado para probar las comunicaciones de la API en diferentes lenguajes, transportes y protocolos. Gracias por asistir a la charla, no dudes en comunicarte si tienes alguna pregunta.

Entonces, puedes escribir un complemento en el lenguaje que elijas para admitir cosas como transportes, protocolos o reglas de coincidencia. Y luego puedes distribuirlo a todos los lenguajes que admitan complementos. Hemos agregado ese soporte a PACT-JVM, por lo que Java, Kotlin y demás, PACT-Go, y hemos lanzado recientemente soporte beta para JS. Así que todos ustedes son los primeros en saberlo. Y el primer complemento oficial que creamos fue protobufs, por supuesto.

Aquí tienes un ejemplo de protobuf, o gRPC/protobuf que falla, donde el proveedor no ha coincidido con el tipo de contenido exacto del consumidor. Entonces, ¿cuáles son nuestras conclusiones aquí? La adopción de microservicios internos multiprotocolo se está acelerando. Y la falta de estandarización para el diseño y las pruebas está contribuyendo a los desafíos de los microservicios en general. Aprendimos sobre la Ley de Hiram y la necesidad de reducir la ambigüedad, y cómo, en realidad, nuestra API no es una especificación en sí misma, es solo una vista de la API. Y las pruebas de contrato son un enfoque que puede ayudar a reducir tanto la complejidad de nuestras pruebas como la ambigüedad inherente en esas especificaciones de la API. Y por último, vimos cómo PACT puede envolver todo esto en un flujo de trabajo estandarizado para probar esas comunicaciones de la API en diferentes lenguajes, transportes y protocolos.

Así que, muchas gracias por venir a mi charla. Espero que haya sido interesante y hayas aprendido algo. Si tienes alguna pregunta, no dudes en comunicarte conmigo a través de cualquiera de los canales a continuación y disfruta del resto de la conferencia. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.