[Contract Driven Development - Post 2] Integration Hell

In the previous article, in this series we discussed the trouble with API mocks because of which we have come to depend on integration tests to identify contract compatibility issues. Picking up from where we left off, let's look at the trouble with integration testing in this article.

Integration Tests

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.

The bottleneck - Integration Testing Environment

Microservices architecture definitely helps us break down features into meaningful components and build many of these pieces in parallel. However deploying each of these components independently is easier said than done.

Consider a mobile application that involves two components, UI and API. These two components can be built in isolation. However, when they are tested together in an integration environment even a single parameter or data type mismatch can render all features (not just the impacted feature) untestable. Irrespective of which component is responsible for the contract compatibility issue, the business/product suffers since the feature cannot be shipped until the issue is resolved, environment is stabilised and the integration testing can resume again.

In the above example, we just saw two components in play. Even small to mid-sized organisations can have several tens to several hundred components (services, apps, data stores, etc.) With an increasing number of nodes in the network even just a handful of broken integrations can render entire environments unviable. This can affect delivery in multiple ways:

1. Inability to promote features to higher environment such as Staging or UAT
2. Debilitating levels of rework for the teams involved to fix compatibility issues
3. Complete loss of predictability for business in terms of when a feature will be available
4. Blocked path to production even for emergency fixes

Cycle Time - Feedback loop

Integration testing stage is at least two or three steps from the developers local environment. This means from the time a line of code is written, to the time we get feedback on the component being contract compatible can vary between a few hours to a few days based on the context. 

While integration testing will most definitely identify contract compatibility issues, the delay involved makes it an ineffective and inefficient mechanism. By the time the feedback is received by the development team, they may have moved on to the other features etc. and they need to context switch to resolve the contract compatibility issue. Such context switching takes a toll on the morale of the team. This integration hell can reach a point where we have to resort to antipatterns such as stabilization sprints where we completely stop feature delivery.

This is exactly why we believe it is absolutely essential to Shift-Left the identification of contract compatibility issues and kill integration tests. In our next post we will be looking at tools and techniques that will help us bridge the contract communication gap.

Related viewing - Youtube playlist on shift left and contract driven development

Stay tuned to know more. Signup for our newsletters on https://specmatic.in.