Why are we talking about Microservices?
A significant amount of traction has been built in past couple of years around “microservice architecture”. Its been talked about in almost all major developer conferences and seminars. It has acquired quite a lot of interest in the active development community and slowly people have started writing about it.
Recently I found an interesting technology curve on Twitter by InfoQ [Image Courtesy of InfoQ]. If you notice the first segment which is Innovators, you can spot Microservices there along with Reactive programming and Machine Learning. It is evident from this curve that the microservices are going to play an important role in near future and a majority of the community still needs to explore and adopt.
Martin Fowler (ThoughtWorks) has written quite a lot about it here . And you can also find couple of articles on infoQ .
Some of the early adopters who have moved from monolithic architecture to microservices architecture are Netflix, Amazon, Paypal, Twitter. As microservice is becoming more popular and is being adopted fast, it becomes essential for test engineers and organisations to align their testing strategy with the architecture of the application. This requires change in perspective from traditional way of testing applications.
So while the developers have slowly started implementing it and pushing guidelines on the way it has to be implemented, there is also some interest picking up in how to go about testing it.
Some questions you may have ?
a) Why is it important for test engineer ?
Essentially a microservice is a small, independent, deployable piece of software which encapsulates a definite business logic. As it contains business logic, it makes perfect sense to test the logic right here versus testing it as part of the bigger application.
b) What do developers test ? and What test engineer should focus on ?
While developer’s focus is to write tests for each of the layers in microservice architecture and various integration points, test engineer’s focus is to write tests for the business logic which it encapsulates, and its behaviour in various unexpected conditions
c) Can I exercise a business use-cases (System test) ?
The answer is a resounding YES. While each microservice encapsulates certain business logic, collaboration between microservices achieves a use case or system test. In some cases an orchestration service would be created which internally interact with one or more services to achieve certain use case.
d) Wouldn’t the traditional approach of testing work ? if not why ?
In most of the traditional testing strategies, entire application is considered as a blackbox. Testing and test-automation is done at UI layer predominantly. Also, in most cases test engineer is not bothered about the internals and mechanics of the application under test.
Whereas to test microservice architecture effectively and comprehensively, test engineer needs to understand the purpose of each service, boundaries, interactions with other services and more.