Pact - Consumer-Driven Contracts
Pact is a testing tool, where the business contracts are driven by consumers.
In general, we have some terms that deserves to be highlighted:
Contract
Business agreements between the consumer and the provided API.
Consumer-Driven Contract
Development of the whole API system by the consumer vision, not only by the coders.
Pact
A tool that ensures Contracts are always working, even when any change is needed.
How does it work?
Pact acts on the consumer side-request storing its needs and then returning everything to the API.
What does this mean?
This means that, for example, if the user sends an extra value on the request’s key-value field that the API does not expect, Pact will ensure and protect the integrity of the API so it does not suffer an error when trying to retrieve that data, which it still can not identify as valid.
Okay, but, the consumer sent this new data for some reason, right? So you need to identify them.
For that, we need to rescue what Pact saved from the request that the consumer did.
There is another term called Pact Broker, which is nothing more than a storage where Pact stores the data until they actually reach the API.
Through this process, you can already know what changes need to be made in the API so that the consumer has his contracts working perfectly. Thus, through requests from the API provider with stored Pact data, changes can be made.
Oh, but I already have an end-to-end test environment and I use Docker!
Ok, let’s go.
Even with hard-coded test environments and the use of Docker, the problems still exist. We can only say that they are softened.
Pact’s goal is to ensure the integrity and availability of services throughout the architecture. Also, it can be more practical and faster, since you do not have to build an end-to-end environment, which can get confusing and messy over time. In addition, manual testing is also not required.
If even with the speed and reliability that the tool brings you still do not feel convinced, I tell you another Pact’s feature… It might be the most interesting:
Efficiency!
- the contracts are verified and generated automatically.
- it does single test integration: in a microservices architecture, where a service needs other services in order to return a result to an API, for example, it would no longer be necessary for these other services to be up if Pact were already there.
Today, there are some Pact implementations and frameworks:
- Ruby Pact
- JVM — Pact / Scala — Pact
- .NET Pact
- JS Pact
- Go Pact
- Swift / Objective — C Pact
An example of Pact implementation can be seen in the following image where the Animal Service receives a mock and that’s where the magic happens:
The usage of Pact is indeed interesting and yields a much more satisfying result than common test environments. Therefore, by comparing a basic local mock with Pact, the following characteristics can be realized:
In a nutshell, Pact can also be compared as follows:
Did you feel convinced to try Pact? Good, tell us in the comments!
We will love to know if you discover something new that we don’t know yet.
See you!
