Microservice architecture is no longer a strange term. There are many discussions about testing approaches in microservice based systems too. For example, this article explains a very nice strategy to adopt when testing a solution based on microservice architecture.
I thought to share some of my recent experiences with microservices testing and how microservices enable testability of a complex distributed systems. Note that, this post is not about suggesting another strategy for testing microservice architectures but some key learnings in testing microservices.
Microservices has become a widely discussed topic during the last few years. In September 2011, well before the microservice term was introduced, I did a session on SOA testing in open source software conference, WSO2Con. I have introduced a component based testing approach for SOA during my presentation and discussed about various levels of testing in a service-oriented solution.
I highlighted the importance of component level testing in detail during that presentation and suggested it as one of the key pieces in any SOA test strategy.
After 2-3 years, I see the same methodology is being suggested for microservices testing by many industry leaders/technical advocates. The strategy that I presented back in 2011, made possible mostly under microservices architecture since it enables independent development/deployment of services.
Amazon has been a pioneer in service oriented architecture since its inception and each functionality/feature at amazon is built as a webservice. You could find more information about this in some public references such as this and this. Amazon has been indirectly adopting microservices architecture as explained in those references. Since I was employed at Amazon nearly 1 year back, I got the opportunity to observe and then adopt many service oriented testing strategies that I discussed during the early days of SOA. This post is intended to summarize two key points related to testing in microservice architecture.
Microservices architecture reveal a new set of boundaries of individual components in a software. This allows higher level of decomposition of software which can be tested quite independently.
For example, feature X is decomposed into restful web services (or APIs) X1, X2... Xn. A good microservice should be independently developed and deployed. Thus some of these individual web services may just provide an interface to CRUD (Create, Read, Update, Delete) operations in a database. Testing such a service should be trivial through automated tests (e.g:- HTTP clients). In case the service consists of multiple dependent services which are not available at the time of testing, stubbed version (mocks) of those services should facilitate proceeding with individual services testing.
When the service is integrated with other dependent services, the same set of tests with minimal or no modifications could be run as integration tests.
With these automated tests, microservices are deployed to production without minimal human intervention.
Testing in microservices architecture closely resembles well-known test pyramid. I will relate the layers in test pyramid into microservices testing and discuss further in my next blog post. Stay tuned!
I thought to share some of my recent experiences with microservices testing and how microservices enable testability of a complex distributed systems. Note that, this post is not about suggesting another strategy for testing microservice architectures but some key learnings in testing microservices.
Microservices has become a widely discussed topic during the last few years. In September 2011, well before the microservice term was introduced, I did a session on SOA testing in open source software conference, WSO2Con. I have introduced a component based testing approach for SOA during my presentation and discussed about various levels of testing in a service-oriented solution.
I highlighted the importance of component level testing in detail during that presentation and suggested it as one of the key pieces in any SOA test strategy.
After 2-3 years, I see the same methodology is being suggested for microservices testing by many industry leaders/technical advocates. The strategy that I presented back in 2011, made possible mostly under microservices architecture since it enables independent development/deployment of services.
Amazon has been a pioneer in service oriented architecture since its inception and each functionality/feature at amazon is built as a webservice. You could find more information about this in some public references such as this and this. Amazon has been indirectly adopting microservices architecture as explained in those references. Since I was employed at Amazon nearly 1 year back, I got the opportunity to observe and then adopt many service oriented testing strategies that I discussed during the early days of SOA. This post is intended to summarize two key points related to testing in microservice architecture.
Individual services testing
Microservices architecture reveal a new set of boundaries of individual components in a software. This allows higher level of decomposition of software which can be tested quite independently.
For example, feature X is decomposed into restful web services (or APIs) X1, X2... Xn. A good microservice should be independently developed and deployed. Thus some of these individual web services may just provide an interface to CRUD (Create, Read, Update, Delete) operations in a database. Testing such a service should be trivial through automated tests (e.g:- HTTP clients). In case the service consists of multiple dependent services which are not available at the time of testing, stubbed version (mocks) of those services should facilitate proceeding with individual services testing.
Microservices enable continuous deployment
One of the major advantages of adopting microservices architecture is, it facilitates fast phased deployment of web services in fully automated fashion. Testing teams can start working on service level automated tests well before the code is pushed into testing environment. Service stubs and API specs allow testing team to build basic test utilities in advance. Once the code is ready in test environment, the automated tests exercise all resources in RESTful API (microservice).When the service is integrated with other dependent services, the same set of tests with minimal or no modifications could be run as integration tests.
With these automated tests, microservices are deployed to production without minimal human intervention.
Testing in microservices architecture closely resembles well-known test pyramid. I will relate the layers in test pyramid into microservices testing and discuss further in my next blog post. Stay tuned!