There had been different conversations around testing microservices. Apart from Cloud, Mobile, Bigdata this is also one of the topic that saw some momentum recently. Naturally, being testers it is important to know how are we going to test the microservices.
Through this blog I am sharing my views on microservice testing. The discussion is open; happy to know your feedback and comments...
So what is micoservice?
Although the terms is appearing in most recent discussions, it is not really something new.
This architecture / product style has already been in place for quite few years. It has become popular as probably it shows the ability to adjust the architecture to constantly changing requirements.
We can look at microservices as small, independent applications communicate between each other. Generally the communication is through HTTP, usually with use of REST protocol.
Not just new systems, but even old & proven systems are being written into this new architecture to meet the demands of post smartphone & mobile network timezone.
How to test it?
From tester's point of view - micro services need the proven testing levels as a part of test approach - i.e. unit tests, integrations tests, functional (end to end tests). So far nothing much to worry as far as testing levels go.
There is a new level though - Contract testing.
What is meant by contract testing?
When services is exposed to the world for communication, a contract is defined for API. Idea here is to test the service under consideration as black box - and all the services must be called independently and their responses must be verified for both positive and most important negative cases.
Every consumer service is receiving the same output. If more functionality is added, it must not break the service functionality.
Tools like Pact are used in contract testing.
Next level is end to end test:
Although this level remains, it's nature has slightly varied in case of microservices.
It is generally advised that just enough e2e tests are included and most of the features should be covered in unit-integration-contract tests.
It thus becomes little more tricky to build e2e tests.
On top of the functionality it is advisable to consider network aspects in these cases like - like timeouts or packets loss.
Automation:
More automation focus is advised at unit-integration-contract level tests.
Even for e2e test automation - a different perspective can be considered - i.e. to check if some user actions can be automated at service level, ather than UI level through Selenium. So naturally, differnt tool sets would come into picture.
Defects fixing / Debugging:
In case of defects, debugging scenarios with a lot of dependencies to external services can be challenging, here.
Performance:
Testing critical microservices in isolation along with focusing on communication with external data source and external services would be handy.
While testing we can keep tap network contribution and code contribution to the time.
Security:
Security aspects should be factored around areas like - communication between services, data encryption in transit, testing security for each core / critical service in isolation,
So far, it must be clear, that this type of work would demand more technical and devops / testops type of skills; it seems that most of the microservice development happens in such work environment.
Through this blog I am sharing my views on microservice testing. The discussion is open; happy to know your feedback and comments...
So what is micoservice?
Although the terms is appearing in most recent discussions, it is not really something new.
This architecture / product style has already been in place for quite few years. It has become popular as probably it shows the ability to adjust the architecture to constantly changing requirements.
We can look at microservices as small, independent applications communicate between each other. Generally the communication is through HTTP, usually with use of REST protocol.
Not just new systems, but even old & proven systems are being written into this new architecture to meet the demands of post smartphone & mobile network timezone.
How to test it?
From tester's point of view - micro services need the proven testing levels as a part of test approach - i.e. unit tests, integrations tests, functional (end to end tests). So far nothing much to worry as far as testing levels go.
There is a new level though - Contract testing.
What is meant by contract testing?
When services is exposed to the world for communication, a contract is defined for API. Idea here is to test the service under consideration as black box - and all the services must be called independently and their responses must be verified for both positive and most important negative cases.
Every consumer service is receiving the same output. If more functionality is added, it must not break the service functionality.
Tools like Pact are used in contract testing.
Next level is end to end test:
Although this level remains, it's nature has slightly varied in case of microservices.
It is generally advised that just enough e2e tests are included and most of the features should be covered in unit-integration-contract tests.
It thus becomes little more tricky to build e2e tests.
On top of the functionality it is advisable to consider network aspects in these cases like - like timeouts or packets loss.
Automation:
More automation focus is advised at unit-integration-contract level tests.
Even for e2e test automation - a different perspective can be considered - i.e. to check if some user actions can be automated at service level, ather than UI level through Selenium. So naturally, differnt tool sets would come into picture.
Defects fixing / Debugging:
In case of defects, debugging scenarios with a lot of dependencies to external services can be challenging, here.
Performance:
Testing critical microservices in isolation along with focusing on communication with external data source and external services would be handy.
While testing we can keep tap network contribution and code contribution to the time.
Security:
Security aspects should be factored around areas like - communication between services, data encryption in transit, testing security for each core / critical service in isolation,
So far, it must be clear, that this type of work would demand more technical and devops / testops type of skills; it seems that most of the microservice development happens in such work environment.
