Microservices have become the defacto standard for building cloud native applications for the past decade and several enterprises have large internal projects to decompose their monolithic applications into collection of microservices to realize the benefits of this service oriented architecture.
As the move to a microservice world accelerates , I have been noticing an aspect of software engineering that needs to be revisited. Typically for any large project to be successful and sustainable, you have to define a solid testing strategy. This involves building several types of tests which are usually classified as unit, integration and end-to-end (e2e) tests. QE teams follow a system called “Testing Pyramid” to help build these tests which suggests that you invest a lot more in unit tests since they help test the business logic without the noise of external dependencies. Martin Fowler’s article is an excellent read regarding this topic.
But in the world of microservices, most of the business logic isn’t centralized inside a particular microservice and it is usually a complex orchestration across different services. In such a world, having a larger corpus of unit test compared to integration tests doesn’t provide the protection you need to run your cloud application. The focus has to shift to a larger battery of integration tests which provide the coverage of the intricate dependencies between the microservices and increase the quality of your releases. It looks more like a “Testing Diamond”.
