Testing applications developed in Microservices architecture.
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 API testing tools which are built around SOA (Service Oriented Architecture) testing. This however may not be cost effective as all services have been developed by separate teams and the time available for testing all of them is not guaranteed.
- 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 Test Driven Development here ensures that the requirements are clearly validated during unit testing. Unit Testing also ensures data persistence within the service and its passing on to other interacting services.
- 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.
Conclusion
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.