An image of a woman experiencing integration hell during contract-driven development.

[Contract Driven Development – Post 2] Integration Hell

Published by: LinkedIn
Author: Naresh Jain

Article overview

In my article “Microservices Integration Done Right Using Contract-Driven Development” that was recently published on InfoQ, I explained how the term is often a misnomer. In the context of this article, when we talk about integration testing we are referring to the aspect of verifying the contract compatibility between components.

Integration Tests require the actual components/microservices to be deployed to a common environment. Because of this integration tests are able to verify the connections between these microservices which was never verified until this point since all the constituent microservices of the application were all built in isolation. While tests running in this environment can exercise/verify internal logic of each microservice, that should not be their focus. Nor is it the best use of integration tests. Internal logic can always be verified through tests lower down in the test pyramid. However, this ability to verify connections by virtue of having all constituent components deployed to an environment also is the Achilles heel of integration tests.

Share