KAFKA CONTRACT TEST WITH PACT
Hello! In this article, we will talk about how we, as the Fraud team, decided to write contract test.
Our team’s business is catch the frauds and we are in contact with most teams so needed to write a contract test. Because we should not be affected when there is a change on the provider or consumer side. If there is a change it will allow us to be aware beforehand.
Why contract testing?
Contract tests assert that inter-application messages conform to a shared understanding that is documented in a contract. Without contract testing, the only way to ensure that applications will work correctly together is by using expensive and brittle integration tests.
Contract testing will make your life easier in four main ways. Contract testing:
- Helps Providers make changes without being scared of accidentally breaking their Consumers;
- Lets Consumers know that the APIs they consume won’t suddenly break;
- Allows Consumers to develop against API definitions before the Provider API has actually been developed;
- Makes integrating and testing a service in a micro service landscape easier;
- Serves as an efficient communication tool between Provider and Consumer teams.
- Contract testing lets everyone relax and be assured that the APIs won’t up and die.
A failure in a contract test shouldn’t necessarily break the build in the same way that a normal test failure would. It should, however, trigger a task to get things consistent again. This may involve updating the tests and code to bring them back into consistency with the external service. Just as likely it will trigger a conversation with the keepers of the external service to talk about the change and alert them to how their changes are affecting other applications. For detailed information, you can take a look at the Martin Fowler article that I refer to.
Talk about how we apply the contract test.
Let’s start.
PACT
We started to search tool to write contract test and we decided to use PACT.
Pact solves the problem of keeping the two sets of tests in sync by use of a “contract”, also known as a “pact”.
During the consumer tests, each request made to a Pact mock provider is recorded into the contract file, along with its expected response.
A Pact simulated consumer then replays each request against the real provider, and compares the actual and expected responses. If they match, we have verified that the simulated applications behave the same way as the real applications. This means the two real applications should communicate correctly when they interact in real life.
There are two main types of actors in contract testing, Providers and Consumers. The Provider is an application responsible for publishing an API; a Consumer of the Provider is another application using (consuming) said API.
Add Pact dependency libs to project pom.
For Consumer app:
For Publisher app:
Kafka JSON Consumer:
We can writing JSON messages to Kafka with Pact. We will use Junit5 annotations. Although we’re writing the consumer test, we’ve also named the provider. The most interesting part here is the body. We’ve defined it to have a single String field. We don’t need to do all the assertions that “service” tests might be interested in, we just need to be sure that our application understood the input.
You might want to run and publish the consumer test. This is what it looks like on the Pact broker:
Kafka JSON Provider:
Consumer and provider must match what we put in the corresponding consumer test. We’ll also add a @BeforeEach which tells Pact we are running Message related tests, and implement the @TestTemplate method.
Similar of the consumer test, we will need to get hold of a Kafka Serializer, which we should obtain through looking up the configuration of our production code.
The KafkaJsonSerializer will take our domain object and turn it into a byte array. We pass this back to Pact which will compare it to what is held in the Pact broker.
To sum up
In this article, I tried to explain how you can use contract test with PACT. It’s useful for us because of decrease our bug counts and alert before defacts. I hope it is helpful.
If you want to be part of a team that tries new technologies and want to experience a new challenge every day, come to us.
Thanks for the readings 😊
