Microservice Architecture and its Testing Techniques
Posted: Nov 21, 2017
Technologies have adopted and aligned themselves to meet the ever-changing business demands and in this process newer techniques and fundamental methods have evolved in software design and development. The evolution of micro-services has been the result of this process and has in turn introduced many challenges in testing applications designed with a micro-service architecture.
Micro-services break down the software architecture of an application into smaller units as per its business needs. This results in systems which are more flexible, highly resilient, easily scalable and can be developed by separate sets of individual teams. It is a difficult task to formulate effective testing strategies for applications designed with such an architecture.
Challenges of testing API and Microservices
- As micro-services are developed by teams working on multiple technologies and frameworks, and are integrated over light-weight protocols, the testing team inclines on using the Web
- Each micro-service is considered to be independent of each other, although they are interconnected to one another. Hence, the main challenge here is to be able to define the right amount of testing required at each point in the testing life-cycle.
- When these services are integrated with another service or API exposed to the external world, then a simple API testing tool proves ineffective.
- With micro-services, there is no requirement for a service level aggregator and data storage is managed by individual units. This complicates the extraction of logs during testing and data verification.
In order to overcome the challenges listed above, Mike Cohn’s test pyramid can be used for understanding the amount of testing required.
This pyramid emphasizes on a bottom-up approach to testing, the number of tests and the efforts to be factored in each stage.
Testing between Micro Services and Third Party API
Let us review a scenario where a service in an application consumes or interacts with an external API. The testing strategy in each phase of the test cycle can be defined as follows:
- Unit Tests cover testing for various functions defined by the service. Including a
- Contract Testing: This is a contract integration testing and needs to be verified with a live instance of the external service periodically. This testing is done in order to ensure that there is no change in the external service that has been published and used by the user.
- Integration Testing: Live integration testing is not recommended. However, if API Sandbox is not available for testing, then the integration contract testing needs to be performed thoroughly for verification.
- E2E Testing is performed in order to ensure that there are no failures in workflows that may be integrated with the internal service. A few monitoring tests can be set up to ensure there are no uncovered inconsistencies. E2E tests can be run at regular and pre-defined intervals to spot any changes.
With changes and improvements in software architectures, application design and testing have also undergone fundamental changes. Testing teams working on applications developed in micro-services architecture need a good understanding of the behavior of such services, tools and strategies in order to overcome potential testing challenges.
Michael works for Cigniti Technologies, which is the world's first Independent Software Testing Company to be appraised at CMMI-SVC Level 5, and an ISO 9001:2008 & ISO 27001:2013 certified organization.