The goals of microservices architectures and end-to-end tests are in fact conflicting. Therefore we must consider our options carefully before we decide to implement this kind of microservice tests.
Microservices continue to be all the rage in software development these days. They are meant to be developed, delivered and deployed entirely independent of each other. However, in most real world scenarios the only meaningful way of running them is in combination with each other.
From a testing perspective, past experience teaches us that software components which interact with each other should also be tested in conjunction because verifying that a single unit works properly in isolation is simply not sufficient to guarantee that the entire integrated system works as intended.
Furthermore, one of the key advantages of a microservices architecture is that it allows for continuous integration and continuous deployment. Therefore all testing stages are typically fully automated and incorporated into some sort of CI/CD pipeline. Then, if the end-to-end testing stage fails, the delivery of all (!) involved microservices is blocked until the causes of the failing tests are fixed.
Hence, the goal of ensuring software quality through end-to-end testing and the goal of rapidly integrating and releasing software components are actually conflicting.
In this talk we will share our experiences regarding this dilemma that we made in a large scale real world project involving 200+ developers organized in 30+ teams and a landscape comprised of more than 100 microservices.
We will discuss the pros and cons of end-to-end testing microservices, the biggest issues and obstacles we faced, best practices and anti-patterns we identified and also look at alternative approaches.