What are different types of tests for microservices applications?
We get asked this question quite a bit. So here is a summary of our point of view based on reality rather than a microservice testing framework purist perspective.
You will find several excellent articles on Martin Fowler that deal extensively with this topic:
The Practical Test Pyramid , etc.
These articles offer in-depth treatments of the topic, and provide an excellent basis to plan.
However, based on my interactions with our customers, my observation is that this framework is very theoretical, and in practice, this is not what most real deployments look like.
Most teams we talk to are migrating from a monolith to a microservices architecture. The changes happen incrementally. For testing, they are starting with existing unit tests and UI tests for the monolith, and they want to efficiently update the existing tests as they incrementally break the monolith up into microservices. The majority of the end-to-end functionality stays the same during the migration, and the migration is rolled out incrementally over a period of time.
API testing typically follows unit testing and UI testing. Some teams want to focus on end-to-end API testing first, while other teams are focusing on what we call service testing — both validating the contracts as well as the functionality for each service. Most companies we talk to favor one over the other in order to get going. I suspect that over time they will adopt both.
The demarcation lines between ‘integration’ and ‘component’ testing are fuzzy in practice. The companies we talk to do not obsess over ‘integration’ vs ‘component’ testing. They want API testing — which can be end-to-end or for some sub-system. We see a greater leaning towards testing individual services than a set of services at a time (“component testing”??) By mocking the API behavior accurately, it becomes possible to test a single service, or a collection of services as a single entity.
The key challenge in implementing this type of service testing is the creation and maintenance of mocks. At Mesh Dynamics, we put a lot of effort into making it effortless to create accurate mocks at scale such that engineers can create service tests easily with minimal effort.
To summarize, what we see in reality is people start testing microservice applications typically with (mostly) existing unit tests and UI tests as they migrate from a monolith to a microservices architecture. Then they add API testing — whether it is end-to-end or at the service/component level.
In addition, people also adopt load testing, resilience testing, and chaos testing (for example, Netflix chaos monkey) — depending on the level of sophistication of the team, resources available, and priorities.
Please contact us at Mesh Dynamics if you are interested to learn more about our approach to implementing service testing for microservices applications.