μServices Contract Testing

The biggest challenge in building a reliable CI/CD pipeline for the μServices architecture based application is the Integration Testing. In the beginning it looks pretty straightforward, Let us start with a new μService you are building for your new shiny μServices Architecture based application. Let us say your service is dependent on 5 other μServices which in turn are dependent on 5 other μServices. 

You start with a mocking strategy for some of the dependent μServices let us say the one which your service is not directly dependent, and for the other directly dependent μServices you use docker compose to spin up the required services for the integration tests. 

And then you describe your integration scenarios in say Gherkin language which makes them easily understandable. Finally you implement those Gherkin test scenarios using say REST client etc. 

And viola you have perfectly working integration test-suite for your μService, which can be put in pipeline as an integration test stage.

But anyone who has implemented such an integration test stage will know the pitfalls that become visible immediately after the implementation. These pitfalls are directly dependent to the number of dependent μServices and the how often they are changing. You have to ensure that your mocks are always up-to-date, and the docker images for the μServices must be of the right versions. Maintaining the mocks and the docker-compose for the dependencies could easily become a nightmare impacting the reliability of CI/CD pipeline.

Over the last two years, I have used multiple strategies to tackle the maintenance of integration test-suites and dependencies changes. This included proper versioning strategies for docker images for the μServices, implementing a robust mocking strategy including automated mock recording and sharing of the mock files within the CI/CD pipeline for different μServices. But these strategies have failed as soon as the μServices graph gets more and more dense.

In the last 6 months, I started looking at Consumer Driven Contract Testing for μService integration. I looked at the tool PACT which is available in Ruby and Java. The contract testing approach makes perfect sense for testing μService integration. The Provider-Consumer model for writing the integration tests is very intuitive particularly in the context of μServices exposing RESTful API.

In the upcoming articles, I would detail out how to implement a Contract Testing stage using PACT-Jvm and PACT-ruby for the uServices. This includes the automatic validation using the Swagger specification.

Stay tuned, in the meanwhile read this excellent article on why you should use Contract Testing for μServices Integration Testing.

image credit: http://techblog.newsweaver.com/why-should-you-use-consumer-driven-contracts-for-microservices-integration-tests/