Testing with FITR

This is the first in a series of Visual Connections blogs focused on exploring continuous testing.
Our goal is to share industry best practices, help you reduce costs and testing efforts, and increase your return on investment (ROI) potential.

Consumer-Driven Contract Testing

By:
Fred Deese | Visual Connections President & CEO
Bas Dijkstra | Visual Connections Testing Engineer & Test Automation Expert

In response to the increasing demand for delivering high-quality software at speed, many organizations have adopted -or are in the process of adopting- a Continuous Delivery strategy. A vital part of this strategy is the effective leverage of test automation to have insight into current application quality at all times, a process known as Continuous Testing.

Mainly, these Continuous Testing efforts are targeted towards writing and executing functional automated tests, anywhere from the unit test level all the way towards full-stack integration and end-to-end tests. However, to get a complete overview of the current state of application quality, only performing functional test automation is not enough.

This three-part series introduces three of the many other techniques that you can leverage as part of your Continuous Testing approach to get a better and more complete indication of application quality at all times during the software development lifecycle.

Consumer-Driven Contract Testing

An increasing amount of teams and organizations are shifting towards a microservices-based architecture for their application portfolio. Compared to traditional monolithic or Service Oriented Architecture-based applications, application that follow the microservices design principle are -when done well, of course- much more flexible and scalable. These applications are built out of small, loosely coupled components (microservices) that communicate with one another to form applications. These components can be built in parallel, in different teams (or even organizations) and it should, at least theoretically, be relatively easy to swap out a component that’s causing troubles for another part that does the same thing, but better.

Adopting a highly distributed application architecture does raise an important question, though, when it comes to testing:

“How do we ensure that, over time, all components are able to communicate with one another at all times?”

Consumer Driven Contract Testing (CDCT) (https://martinfowler.com/articles/consumerDrivenContracts.html) is one way to address this question.

CDCT revolves around contracts that define an agreement between a service consumer (‘client’) and a service provider (‘server’). In this contract, the consumer party defines expectations they have about the responses returned by the provider, given a certain type of input.

As an example, consider a microservice such as http://api.zippopotam.us, a REST API that returns location data associated with a given country ISO code (e.g., ‘us’) and zip code (e.g., 90210). The consumer of such a microservice could, for example, have these expectations that may be formalized in a consumer-driven contract:

“When I request location data for a zip code that exists in the microservice database, I expect a response status code equal to HTTP 200”
“When I accidentally specify a zip code that is improperly formatted, I expect a response status code equal to HTTP 400”
“When I request location data for a zip code that exists in the microservice database, I expect that the response body is in the JSON data format and that it contains at least one place name. This place name should be a String value.”

From these expectations, the consumer generates a contract that is given to the provider, who can then use it to check whether their current implementation is able to satisfy the expectations in the contract.

There are several tools available nowadays that automate the entire CDCT process, most notably Pact (https://docs.pact.io/). These tools can be used to automate the entire CDCT flow, from automatically generating the contract on the consumer side, to distributing it to providers (using a centralized contract broker), to enabling providers to upload their contract verification results to the broker. This last step creates a central source of truth with regards to the status of all communication between individual microservices consumers and providers.

Moreover, tools like Pact are built to be made part of Continuous Delivery pipelines, and while they do not solve all communication and integration issues that can occur in a highly distributed system, they do give valuable insight into whether different components can still communicate with one another. This makes them a useful addition to testing the internal business logic of individual services, especially in microservices architectures.

For a more in-depth look at CDCT and Pact the reader is referred to this blog post series: https://kreuzwerker.de/post/introduction-to-consumer-driven-contract-testing

Blog 1 in this Series

Fred Deese

After nearly a decade of providing advanced web and application development services to both the private and public sector, Fred Deese co-founded Visual Connections, an information technology consulting firm, in 2007. As Chief Executive Officer of the company, Fred is focused on new business development, overall company positioning, and client relationships.

Since the company's inception, he has held project management positions on many prominent and complex commercial and government IT projects, personally providing the services that have made Visual Connections widely recognized by its customers for its innovative technologies and quality work. See Full Bio Here

Bas Dijkstra

I help teams and organizations improve their testing efforts through smart application of tools.

In my 13+ years in the testing profession I have successfully designed and implemented test automation solutions for a wide variety of clients. I’m currently mostly active as a trainer, teaching people and teams how to make their first or their next move in the world of test automation.

I love to share and expand my knowledge of the test automation field by delivering talks, workshops and training courses, both at conferences as well as on-site with my clients.

You can contact me on LinkedIn via https://www.linkedin.com/in/basdijkstra or through my blog OnTestAutomation.