Microservices and Testing Pyramid

Adoption of microservices have changed the way we build software. It's a slim down version of SOA and impacts all areas of SDLC. A successful adoption will require mindset change of how we think, design, test, build, deploy and monitor our products.

In this post, I want to discuss Testing methodology which took a 180 degree turn for me. Conventional testing pyramid implies that Unit tests are the most important form of tests. It carries the heaviest weightage. Unit test identifies a small unit of code and test it with combination of parameters. Unit tests are then followed by Service tests. Service tests are the API tests for your service. Usually it consist of a test-suite that includes spinning up the service under test and all its dependencies. A test client can call service API with different inputs and validate that the service is working as expected. At the top of the pyramid are the UI and E2E tests. A typical testing pyramid looks something like:


This pyramid makes perfect sense in the monolithic architecture. Let's take an example of everyone’s favorite calculator. I will write a calculator utility classes. It will have functions to perform mathematical operations. It will be packaged in a binary. The monolithic service will consume this binary at run time using a profile catalog. This binary will be hosted with hundreds of other binaries within this service. All colocated binaries can use the Calculator for their mathematical needs. In this monolithic setup the best way to test functionality is using Unit tests.

Microservice setup is different than monolithic. In microservice architecture Calculator is a standalone functional service exposed over an http API. It can only be consumed by making http calls. Binary coupling is discouraged in microservice architecture. Here is Ben Christensen famous talk on the topic. An ideal microservice should have well defined responsibility with in a bounded context. This kind of setup makes it easy to write effective Service tests. The testing pyramid for microservice architecture should look something like:

What about the cost? We all love writing Unit tests. They are easy to setup, cheap to write (if done at development time), cheap to run, very reliable (meaning if they break - they break for a real reason and not some environment instability). They also produce nice looking code coverage reports. Service tests on the other hand are difficult to setup and expensive to run. In the future posts, i will discuss how adoption of Docker has made it super easy to write reliable and fast Service tests.
Location: Boston, MA, USA

Popular posts from this blog

Break functional and orchestration responsibilities for better testability

Image
Microservice architecture paradigm fits well within the Unix’s first principle/philosophy: “Make one program do one thing well”.  We love creating small services which has identity of its own (within a bounded context). These services have their own CI/CD pipelines and provides loose coupling b/w components which significantly improves our ability to deliver code to production. In reality, a workflow can span multiple services. Its very common to find scenarios like below: In the above example, a workflow spans 3 services (Service-1, 2 and 3). Service1 receives the original request. In order to process this request, it GET(s) some data from its dependent services(d1/d2/d3). It further runs some business logic and produces an intermediate response #A. It then makes a state mutable call (POST/PUT/DELETE/PATCH) to Service-B using #A as input and waits for its response. Service-B follows the same paradigm and the workflow ends when all services returns.  The scenario above
Read more

Prefer Consumer over Integration Tests

Image
Recently I attended an RCA meeting for an incident that happened in prod few weeks back. The issue was somewhat of a 2nd degree failure. To put it in simple terms, lets say a workflow composed of two services - A and B. When user performed an action from the UI, it made a call to Service A which then internally called service B with some parameters based on user preferences. In this case, due to some unusual combination of preferences, Service-A ended making call to Service-B with parameters that Service-B didn’t fully understood. Solution - Write an integration test to cover this scenario. Reasoning - Since this involved 3 different components (User Preferences, Service A and Service B), it should be covered by an integration test. More Reasoning: This is sort of the usual way of thinking about the integration tests - meaning whenever there are multiple services involved, we immediately think about writing an integration test. But is this the right approach specially in microserv
Read more

Microservices and Tech Stack - Lessons Learned

Image
In this blog, I want to talk about how our technology stack has evolved over time while transitioning from Enterprise to adopting Microservice architecture as a main stream development practice and share some of the lessons learned. Tech stack for us has evolved from being a Monolithic Enterprise to Cloud to now Microservices. During Enterprise days, it looked something liked this: At the app layer, we had a desktop client written in Windows form and WPF. The app would talk to the Service Layer which was SOA architecture written completely in C#. It was the only language allowed for us to use. These were monolithic and stateful services communicating to each other over WCF. We used SQL server as backend storage. All this get deployed on premise meaning our clients buy our software and host it on their own hardware. I work for Finance industry (Stock Market to be precise) and they were sort of late adopter of public cloud. They absolutely hated the idea of putting their data on p
Read more