[Day 12/12] Microservices - Should We Test Them?



What are Microservices?

Microservices — also known as the microservice architecture — is an architectural style that structures an application as a collection of loosely coupled services, each of which implement business capabilities. The microservice architecture enables the continuous delivery and deployment of large, complex applications. It also enables an organization to evolve its technology stack, scale and be more resilient with time.


To understand the popularity of microservices, it’s important to understand monolithic applications. A monolithic application is built as one single unit. In a monolithic application, server side logic is bundled together in the form of a monolith, with all the logic for handling requests running in a single process. All updates to this system will entail deploying a new version of the server side application.


While there are, and have been thousands of successful monolithic-based applications in the market, development teams are starting to feel the brunt of such large scale deployment operations. For example, in a monolithic application, any small modification is tied to an entire change cycle, and these cycles are invariably tied to one another. Granular scaling of specific functions and modules is also not possible, as teams have to scale an entire application.  


In order to overcome the growing complexity of managing, updating and deploying applications, particularly on the cloud, the adoption of the microservices architecture took off. Each microservice defines a specific business function, and only defines operations that pertain to this function, making them very lightweight and portable. Microservices can be deployed and run in smaller hosts, and don’t have to use the RAM and CPU resources of traditional architecture. These operations can also be developed in different languages depending on the use case, so a message-board service can be built in Ruby, and the service delivering them to different users can be built on Node.


Microservices and APIs

Microservices use an inter‑process communication (IPC) mechanism to interact with each other. These interactions could be:

  1. One to one, where client requests are handled by one service
  2. One to many, where client requests are handled by multiple services  

If the IPC mechanism involves a request-response cycle, then the most common means of communication are RESTful, which almost always use HTTP/JSON APIs. APIs used as IPCs between microservices are different from traditional forms. These APIs are more granular. Since APIs exposing microservices expose fine grained data, clients may have to follow a one-to-many form of interactions between services to obtain the required data.    


Testing Microservices

Unit and component tests are a common way of validating the behavior of the service being built. The size of the unit test depends on the kind of application it is, often times being the smallest piece of testable software in an application. If a unit test is difficult to write, it often means your test module should be broken down into more independent pieces and tested individually.


Since APIs are the glue for various microservice units to communicate with internal and external services, common integration tests with a functional, performance, load and security flavor can be implemented to ensure your microservice units are running as smooth as possible. Any test you do on a microservices based architecture should provide coverage for every single piece of the inter-process communication at the finest granularity possible.

By combining unit, integration and component testing, we can get better coverage of all the various modules and domains that make up the microservice, validating if the service correctly implements the required business logic.


Further reading


It's your time to participate!

We'll love to hear about your experience with microservices

  • Do you use microservices in your organization? If yes, how effectively have they implemented in into their business?
  • How do you perform any kind of automated tests to your microservice business logic?
  • What issues do you find when performing tests against the APIs that connect various microservices?



12 Days of Software Quality rules:

- Each day, our experts publish interesting industry articles

- You share your thoughts on a topic by commenting an article and vote for the others' comments you like

- Daily, we select a winner based on the number of Kudos his/her comment got.


12 Days of Software Quality Schedule

Community Hero
  • Do you use microservices in your organization? If yes, how effectively have they implemented in into their business?
    • We have two macro-services currently that we have or are developing, and they are a learning process every time. The first one started development a few years ago, and the second one just recently and it seems we've learned from some of our mistakes in the past but found new ones. 
  • How do you perform any kind of automated tests to your microservice business logic?
    • I've built what I call a macro-service project that tests all of the microservies in an end-to-end sort of fashion to verify the data integrity and validation from start to finish matches the business rules we have to follow. This presents its own sort of challenge since there can be many and varied branching paths. As rules get defined, we implement tests for them to check and verify the expected results happen.
  • What issues do you find when performing tests against the APIs that connect various microservices? 
    • The biggest issue I have ran into is how very complex the tests can get when dealing with microservices. Especially when piling them all together under a higher level service that utilizes all of them. This makes it much harder to keep track of them sometimes, and to understand how they all work together. I usually have to draw myself a road map to fully understand how all of the microservices work together and how they talk to each other.
    • Another issue is trying to automate as much of the testing, when some of the "micro" services are large enough to be a regular service, this can be a bog to wade through. Especially when trying to build an end-to-end sort of solution. The size of our Ready API! project files can balloon very quickly. We usually cut back on the sheer amount of tests in our end-to-end and save the lion's share of the tests for stand-alone testing of each microservice.  
    • The last part is if any one microservice in the chain gets updated, this can and does usually trigger regression testing and tends to increase the workload. Not a huge deal but it's something that never quite gets accounted for.


I also wanted to say thank you again to Smart Bear and everyone for these 12 days. I haven't been able to fully participate as I've been busy with a handful of competing testing priorities, but I've tried to stop in and read all of the insight and knowledge everyone has shared. 😄 

Community Manager

Fantastic! Thanks a lot for publishing the article, Keshav.


Guys, this is the last article for our beloved 12 Days of Software Quality. Please leave your comments on the importance of testing microservices here and vote for the comments you like. Tomorrow, at this time, we will announce the Day 12 winner and something more...


Enjoy the last minutes of the event 🙂

@msiadak, thanks a lot for you awesome feedback!

Senior Member

•Do you use microservices in your organization? If yes, how effectively have they implemented in into their business?

Yes. We do use microservices in our organization.

Each service is implemened as a set of distinct functionality. Each of these functionalities consist of business logic. Out of all, one microservice implemetns web UI, other interacts with API which again calls microservice, other that uses backend service calls REST API. Also, for different types of users there are different microservices available which differentiates the fuctionalities and rights of each individual user. Also, each microservice has its own database schema.


So each microservice is a combination of different language they are coded, the way they interact, different databases schema.

•How do you perform any kind of automated tests to your microservice business logic?
Divided the tests in form of:
Unit test cases: Testing individual microservice corresponding to its own database and functionalities.
Call Test Cases: This will verify all the calls made to microservices and their response time along with connectivity. [Response verification]
Integrated test cases:  Inter-service calls to verify the interaction between different services.
UI test cases: How the end user is able to see and interact with the system.
End-end test cases: There are many flows created which checks from the log-in to log-out and all intermediate functionality checks.


There are full test cases designed for each of these kinds tests and are implemented when and where necessary.

What issues do you find when performing tests against the APIs that connect various microservices?

  1. One of the major issue with all these microservices API is Inter-process communication. How and in which format they are communicating.
  2. Also, response time of the services that are interacting plays a biggest facto while automating tests.
  3. Another is, if we are thinking of changing lets say 2 of the services API, then we need to consider all the services that they are interacting and needs to test all the API in which they are sending/receiving the information from other services.


I just recently joined this community and started working on Smartbear. I find this very useful platform and great tool to work with. Thank you so much!! This 12 Days Software Quality initiative is really very useful as we get to know everyone's idea and share knowledge.


Thank you,
Sweta Desai

Community Manager

Hi Everyone!


I'm happy to announce the winner of the last day of the event 🙂

Please join me to congratulate @msiadak and @sweta_desai! Both of them you gave the same number of Kudos. 


Very soon, I'll share the results of the event here. 


Thanks everyone who participated in 12 Days of Software Quality! I hope you enjoyed the event!


Stay tuned 🙂

Community Hero

As the event came to closure, we have seen many new participants along with our existing leaders, sharing their views each day is really fantastic. Congratulations to all the winners and participants through out this event.


Thank you Tanya for bringing new ideas to make the community more active and networking people here on this platform. Great initiative. Kudos to you and your team there who are behind this successful event.


Great to be part of this community. Looking forward to welcome a great 2018.

Users online (359)
New Here?
Join us and watch the welcome video: