Consumer Driven Contract: testeando servicios con Pact.

0
439

Índice

¿Qué son los Consumer Driven Contract?

Es un patrón que nos permite testear y comprobar las diferentes interacciones entre los diferentes servicios de nuestro ecosistema y sus clientes.

En estos tests existen un mínimo de dos actores, un consumidor, que puede ser el cliente, y un proveedor, que será el servicio en sí mismo. El consumidor capturará sus expectativas respecto al proveedor y lo almacenará en un fichero que llamará ‘contrato’, y es lo que usará para realizar los tests. Un ‘contrato’ sería la definición de la forma en que va a comportarse nuestro servicio en base a una solicitud. Es decir, nosotros vamos a definir que el cliente necesitará por ejemplo, los campos nombre, apellido, y edad, por tanto lo que se va a comprobar es que esto campos le siguen llegando, independientemente de que lleguen otros campos que quizás utilicen o no otros clientes, de esta forma aunque el servicio se haya actualizado con nuevos campos, sabemos que los clientes que utilicen la versión anterior siguen teniendo soporte y que no hemos ‘roto’ nada.

Ventajas de usar este patrón

Cuando queremos probar una aplicación que se comunica con otros servicios o APIs, tenemos dos opciones:

– Desplegar todos los servicios y realizar un test E2E.

– Realizar un mock de los servicios y probar la aplicación de forma individual mediante test unitarios.

Vamos a analizar las dos opciones, vamos con la primera, tests end-to-end.

Ventajas:

– Se simula el entorno de producción.

– Se testea una comunicación real con los servicios.

Desventajas:

– Nos puede llevar mucho tiempo desplegar todos los servicios cada vez que queramos testear la aplicación.

– Introduce dependencias

– Feedback muy lento

– Muy frágil

Ahora la segunda opción, tests unitarios:

Ventajas:

– Poco tiempo de ejecución

– No requiere de infraestructura

Desventajas:

– Los servicios serían mocks que quizás no tuvieran nada que ver con la realidad

– Podrías pasar todos los test, ir a producción y fallar

En general es muy útil cuando tenemos arquitecturas basadas en microservicios, algo que está muy de moda ahora mismo.

¿Qué es Pact?

Pact es un framework de código abierto que nos permite implementar consumer driven contract de una manera simple y rápida. Tiene una comunidad bastante activa y soporta múltiples lenguajes. Puedes acceder a documentación mediante este enlace.

Logo Pact

A su vez, este framework, incluye una herramienta llamada Pact Broker, que nos permitirá compartir los contratos de forma remota.

Ejemplo con Pact y Spring Boot.

Para este ejemplo vamos a crear dos aplicaciones, una será el consumidor y otra el proveedor. Consistirá en una aplicación que devolverá los datos de un usuario cuando se le haga una petición. Empezamos creando un proyecto Maven que tenga 2 módulos: Consumer y Provider. 

En el pom.xml del proyecto ‘padre’, añadiremos las dependencias necesarias:

  • spring-boot-starter-web
  • lombok
  • spring-boot-starter-test
  • pact-jvm-consumer-java8_2.12
  • pact-jvm-provider
  • pact-jvm-consumer
  • pact-jvm-provider-spring

Y como ‘parent’, spring-boot-starter-parent.

Usaremos también la librería de Lombok, esto es opcional, es simplemente para ahorrarnos código en algunas clases. Una vez tenemos esto listo, empezaremos por el módulo del consumidor.

Consumidor

Empezamos creando la aplicación que será el consumidor, dado que será la que genere el ‘contrato’, para ello creamos un nuevo proyecto Maven. Con la siguiente estructura:

  • src
    • main
      • java
        • ConsumerApplication.java
        • User.java
    • test
      • java
        • ConsumerContractTest.java

Creamos nuestra clase modelo, User.class:

Mediante las etiquetas @Getter y @Setter, Lombok nos genera los ‘getter’ y ‘setter’.

Ahora, la clase desde donde vamos a ‘consumir’ la API, ConsumerApplication.class:

Ahora vamos a crear la clase de los test que van a generar los ‘contratos’, vamos a llamarla ConsumerContractTest:

Añadimos esta regla para configurar nuestro ‘mock server’, el valor a null sería el host, en este caso al ser ‘localhost’ no es necesario especificarlo.

Aquí le indicamos que inicie el ‘mock server’, con la interacción definida en el método con el nombre ‘pactUserExists’.

Por último, en este método vamos a definir las interacciones, como vemos hemos hecho un ejemplo con un usuario de nombre Pepe, que vive en la ciudad de Madrid y tiene 22 años.


Si ejecutamos la clase ConsumerContractTest, nos generará un fichero como el siguiente:

Este será nuestro ‘contrato’, con el que vamos a verificar siempre el servicio, nos lo genera en la carpeta target/pacts/<archivo>.json, ahora este fichero lo pegamos en nuestro proveedor, dentro de la carpeta src/pacts/<archivo>.json, y con esto estaría todo configurado por parte de nuestro consumidor. Ahora vamos con el proveedor.

Proveedor

Creamos un nuevo proyecto Maven, que tendrá la siguiente estructura:

  • src
    • main
      • java
        • producer
          • User.java
          • UserController.java
          • UserService.java
          • UserServiceApplication.java
    • pacts
      • <archivo>.json
    • test
      • java
        • ContractTest.java

La clase User será nuestra clase modelo al igual que en el consumidor, pero a esta le añadiremos las etiquetas @Data y @Builder de Lombok.

La clase UserController, controlará las peticiones:

Ahora creamos nuestra clase UserService, que simulará devolver un objeto de tipo User:

Los valores no tienen que coincidir con el ejemplo que hemos creado anteriormente, debido a que el test de contrato solo va a comprobar que los campos que utiliza el consumidor son los que mínimamente ofrece el proveedor.

Y por último nuestra clase UserServiceApplication, que iniciará la aplicación:

Y ahora, ya solo nos queda crear nuestra clase de test, que la llamaremos ContractTest:

Con la etiqueta @PactFolder le indicamos dónde encontrar el ‘contrato’ necesario, en la etiqueta @State colocamos el mismo nombre que tenemos dentro del ‘contrato’ en providerStates, para saber qué está testeando. Ahora ejecutamos la clase test y debería darnos ok, podemos jugar y cambiar el nombre de los campos o eliminar alguno para ver como falla, si añadimos uno más no fallará, debido a que seguirá enviando los mínimos que necesita el consumidor. Os dejo el código en Github.

Conclusiones

Como vemos, implementar los test de contrato mediante el framework de Pact es bastante sencillo, y nos permite asegurarnos de que nuestro consumidor proveedor se entienden a la perfección.

Dejar respuesta

Please enter your comment!
Please enter your name here