A microservices architecture is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In her article “Automated Testing Strategy for a Microservices Architecture”, Emily Bache explains how you could transform your test automation approach when you switch from a monolith architecture to a microservices architecture.
The article starts with a presentation of the classical software testing pyramid with unit tests as a base. It then explains that moving to microservices change the perspective on software testing as you might have to start testing mainly through API that were difficult to run and maintain. This lead to the idea of crating a new suite of API tests that were designed to work in a microservices architecture.
Emily Bache retains the following key points for it new test automation implementation:
* The new tests access all the services using REST, which is a much more flexible and universal way to make remote calls than Java RMI.
* Starting to use Data-Driven Testing. This means tgat you generally keep the workflow the same, but vary the data from case to case.
* Starting to use Approval Testing to validate tests. In Approval Testing, you compare the current output with an ‘Approved’ version of that output, that was gathered in a previous test run. Any difference between the actual output and the approved version is marked as failure.
The article discusses then the deployment pipeline needed and configuration management issues created by microservices. Her conclusion is that after a few iterations they have landed with a pipeline structure that is in tune with a microservices architecture. The system tests are divided by team, and each team’s changes are tested together with the release candidate versions of all the other teams’ services.
Read the complete article on http://www.methodsandtools.com/archive/testmicroservices.php