Two years ago we started shifting to microservices. The whole project happened without anything in place. Microservices were created ad-hoc. When someone wanted to create something new or migrate a part of the monolithic API, we'd create a microservice each time. Everything went smooth until we started testing our microservices.
We didn't know where to start!
Mike Cohen's testing pyramid has been the golden standard when it comes to structuring and scripting our testing. The number of unit tests should be kept maximum. The integration tests should be less than unit while UI tests should be kept minimum as possible. This suited quite well for our monolithic codebases.
But what about microservices?
As we move towards independently deployable microservices, the testing becomes coarse-grained. The more coarse-grained a test is, the more brittle and time-consuming it becomes to write, execute and maintain it. At the same time, since microservices are independent, we need new test boundaries at various levels: unit, integration, component.
The concept helps us in understanding the relative number of tests that must be written at each granularity. As we move towards the top layers of the pyramid, the scope of the tests increases and the number of tests that must be written decreases.
While we were trying to fix this for us, we documented our struggle in the form of a blog: Microservices Testing Strategies, Types & Tools: A Complete Guide. This blog isn't about arguing for one form of testing over another but rather to showcase the lessons our team has learned.
If you think there is any way we can improve, feel free to comment your suggestions. or get in touch @HirenDhaduk_ on Twitter.
Top comments (0)