An Introduction to Contract Testing With PactumJS

The integration between services has always been a complex matter. As our digital world becomes more integrated, organisations must develop, maintain and validate integrations between many disparate services and providers to satisfy customer requirements.

One of the reasons behind the complexity of integration is “communication.” This communication not only involves how services share information between each other, but also how teams working on them let each other know about changes or updates.

To ensure all pieces involved can interact successfully, organisations must establish a “contract” to be fulfilled by all parties so the data can flow flawlessly within our system end to end.

So, how do we ensure that those contracts are actually valid and that the terms are met? This is how contract testing was born.

What is contract testing?

Simply put, contract testing is a way to validate that two systems speak the same language when they interact with each other.

There are two key elements that enable us to label each service in our systems: providers and consumers.

Providers are systems which generate and/or modify the data to be consumed. Basically, they receive the request. For example, a provider might be a service that reads a database and provides a summarised view of the data to anyone that requests it.

Consumers are systems that request information from a provider. Consumers generate requests. For example, a website’s front end might request data via an API so it can display some information about a product.

It is important to highlight that a service can be a provider in certain scenarios and a consumer in others, such as in the following example:

• Interaction A: The website requests data from the middleware. In this scenario the website is the consumer (consumes the data provided by the middleware) and the middleware is the provider (provides the data to the website)

• Interaction B: The middleware requests data from the external service. In this scenario, the middleware is the consumer (consumes the data provided by the middleware) and the external service is the provider (provides the data to the website)

To put this within the context of what contract testing is, we can adjust the definition of contract testing to:

A mechanism to validate that the contract between a provider and a consumer has been met.

The easiest way to achieve that validation is to have both systems generate their version of the contract and have a third-party system (or broker) validate that both versions match.

But how do we make sure that the generated documents have a common format? How do we validate that they match? A contract testing framework, such as PactumJS can help out.

What is PactumJS?

PactumJS is a test framework focused on API testing. It provides its users with ways to effectively interact with REST APIs and even mocks their responses when needed.

PactumJS’s functionality keeps expanding as they recently introduced a new tool in beta that enable us to validate the contract between providers and consumers.

Here’s how it works.

First, the provider generates a document containing all the available ways a consumer can interact with them and how they will respond to those interactions. Then they upload it to a Pactum Flow Server.

Consumers generate a document where they list all the interactions they could perform against a specific provider and the structure of the responses they expect. The consumer then uploads that finished document to the flow server.

PactumJS helps consumers and providers generate those documents in a language understood by the Flow Server.

Finally, we interrogate the Pactum Flow Server via UI or API to validate that the contracts match.

To help understand how PactumJS enables contract testing, see the video below or check out this resource.

The positives and negatives of PactumJS

In the time that we have been working with PactumJS for contract testing, we have identify a few of its advantages:

• easy set up
• easy syntax
• clear reporting
• clear “Start” documentation
• fast setup and execution on your first test
• multi-faceted tool for API testing, component testing and contract testing
• container-based Pactum Flow Server

However, not everything is perfect. PactumJS have some downsides as well:

• young product with a reduced community for support
• higher likelihood you might be first to encounter an issue
• contract testing feature is still in beta stage
• Uncertain future

The value of effective contract testing

When quality engineers utilise contract testing efficiently, it enables teams to clearly and quickly identify potential communication issues. It’s crucial to discover these issues as soon as possible, ideally long before they are released into a live environment

PactumJS is a great ally to achieve efficiency with contract testing. Not only does its beta contract testing functionality provide easy-to-understand reports that can be shared at almost any level of the chain of command, but it also provides straight-forward API and syntax. This clarity helps SDETs or developers get a set of tests ready within minutes.

Keep in mind the positives and negatives of this approach. However, PactumJS appears to offer a simple journey toward enabling systems to communicate between each other, reliably and repeatedly.