Consumer Driven Contract Testing [Webinar Recording]

In the previous blog posts of this series, we gave an introduction to consumer-driven contract testing, writing contract tests using Pact JS, Pact Java, and Spring Cloud Contract, and integrating them into build pipelines.

Now that we’ve completed the entire series – It’s time for a quick summary of all the topics that we’ve discussed (or skip straight to the webinar recording 🤩):

In the 1st chapter, Introduction to consumer-driven contracts, we discussed what are microservices, different layers in the Test Pyramid, what is contract testing and where does it fit in. The main idea behind consumer-driven contract testing is to formalize the interaction between a consumer and a provider. The advantage of these new tests is that they are pretty much unit tests: They can be run locally and independently, and they are fast and reliable.

Several tools exist to aid in writing contract tests such as Pact, Spring Cloud Contract, etc. In the 2nd chapter, Consumer-Driven Contract Testing using Pact.js, we discussed what is a pact, how does it works, who would typically implement pact, and more. The pact has client libraries in most programming languages and we choose JavaScript client since both the sample consumer and provider were developed in node.js.

In the 3rd chapter, Consumer-Driven Contract Testing using Pact Java, we discussed how we use pact JVM client to write consumer and provider tests on a spring boot application. The consumer team is responsible for implementing the Pact tests in the consumer codebase that will generate the contract. The provider team is responsible for setting up the Pact verification task in the provider codebase, and for writing the code that sets up the correct data for each provider state described in the contract.

In the 4th chapter, Consumer-Driven Contract Testing using Spring Cloud Contracts, we discussed what is Spring Cloud Contracts, how we can use Spring Cloud Contracts to write consumer-driven contract tests in a java spring boot application. Spring Cloud Contracts allows us to define contracts using Groovy DSL, YAML, PACT JSON, Spring Rest Docs. Consumers suggest the contracts in strong cooperation with the producers. These Contracts are usually stored in a Producer repository or in a centralized repository where both consumers and producers can have access to it.

In the 5th chapter, Event-Driven Architecture: How to Perform Contract Testing in Kafka/pubSub, we discussed what is Event-Driven Architecture, what are events, how does it work in an eCommerce application, how we can use pact to write consumer-driven contracts when streaming model is involved. We used a sample Spring Kafka project to showcase how consumer and provider tests look like in an asynchronous messaging system.

In the 6th and last chapter, Integrating Contract Testing in Build Pipelines, we discussed what is pact broker, how we can integrate consumer-driven contract tests into build pipelines, including publishing the contracts using pact broker.

The entire code snippets we used in the blog series can be found in below repositories:

Consumer-driven contracts do not necessarily reduce the coupling between services. Loosely-coupled services are relatively independent of one another but remain coupled nonetheless. What the pattern does do, however, is excavate and put on display some of those residual, “hidden” couplings, so that providers and consumers can better negotiate and manage them.

Check out a recording of the webinar we hosted on contract testing on June 14th, 2020:

Or start exploring the entire series step by step:

Happy Testing 😎
Sai Krishna & Srinivasan Sekar

Leave a Reply Cancel reply