Integration testing with PACT

Reading Time: 3 minutes

Hello everyone,
In this blog, we will discuss an integration testing tool pact. As we all know during the SDLC we need to test our software thoroughly before giving the final sign-off and releasing it on production.
during the testing phase, we perform various test activities including unit testing, integration testing, and at the end, we perform end 2 end testing along with performance testing, security testing, and acceptance testing based on real use cases.
in this blog, we will mainly focus on integration testing, and how PACT can assist us in it.

Integration Testing traditional way:

For doing integration testing firstly we need to deploy all the related components/microservices in the test environment, then we can start our integration testing. For smaller applications containing only 2-3 microservices it is still maintainable, but what will happen if there are 100 or more microservices are involved??
As the number of microservices will increase it will be a little difficult to maintain the deployment and testing of all those microservices in the test environment.

The problem with integration tests

Before we deploy an application to production, we need to be sure it works correctly with the other applications with which it integrates. To do this, traditionally we run integration tests using “live”, deployed applications.
Integration test gives us the confidence to release but there are some drawbacks related to it:

  • Slow
  • Fragile
  • Test data management
  • Test environment management
  • All-at-once painful deployments
  • Teams wait on build queues

Testing through Simulated applications:

By testing each side of an integration point using a simulated version of the other application, we get two sets of tests which

  • run independently
  • give fast feedback
  • are stable
  • are easy to maintain

But no confidence about how our application will behave in real world after release.

How Pact helps – the consumer side

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.

How Pact helps – the provider side

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.
Using PACT we can 

  • run independently
  • give fast feedback
  • are stable
  • are easy to maintain

Gives Confidence as well that the application will work in the same manner after release.

The primary advantages Of Using PACT are:

  • We can continuously evolve our codebases knowing that Pact will guarantee contracts are met.
  • We can find out before we deploy whether or not your applications will work together – there is no need to wait for slow e2e tests.
  • Pact is fantastic tool for developing and testing intra-organisation microservices.

In our next blog we will do some hands on with pact, how it actually works.



Written by 

Vandana is a Sr. QA Consultant having experience of more than 2.5 years. She is familiar with the core concepts of manual and automation, postman and Newman are her expertise. She is always eager to learn new and advance concepts in order to expand her horizon and apply them in project development with her existing knowledge. Her hobbies include reading novels and listening to music.