Software testing pros know that quality assurance (QA) in microservices architecture needs a totally different approach as compared to monolithic application architecture. Although microservices architecture enables complex applications to be developed rapidly and reliably, the existing QA strategies do not always apply. Each microservice needs to be developed and delivered according to its own schedule, and this is a major reason why QA is more complicated in microservices.
In this article, let’s discuss the QA perspective on microservices. But first, let’s first understand a bit more about microservices (for those who need that essential background!).
What are microservices?
Microservices or microservice architecture is an architectural approach to building applications where a single application is built by using a set of small services. Each small service (also known as a function) runs its own process and is loosely coupled so that one team’s changes won’t affect the entire app.
As opposed to a monolithic approach, each service can be built and deployed independently. This enables individual services to function and fail without negatively affecting other services. These small services are –
- Highly maintainable and testable
- Coupled loosely
- Independently deployable
- Organized around business capabilities
- Owned by a small team
In a nutshell, microservices architecture is an ideal way to build apps for DevOps and CI/CD. Its adoption is quite impressive as well.
As per a survey by O’Reilly, microservices adoption is quite mature. About 61% of the survey respondents said that they’ve been using microservices for a year or more while for 28% of the respondents, it was three years or more.
QA in microservices
QA and software testing in microservices requires a different approach since the testing team needs to begin testing microservices in the design phase itself.
In a microservices architecture, there is more reliance on over-the-wire (or remote) dependencies than on in-process components. So, the QA strategy needs to be adapted accordingly.
While conducting microservices QA, one must keep the following three things in mind –
- The code should do what it is supposed to be doing.
- When it comes to sharing feedback, be quick and reliable in sharing it.
- The overall maintenance should be made easier.
Let’s now take a quick look at various testing strategies for microservices.
- Unit testing – It is important to validate each microservice separately. Unit testing involves keeping the test units as small as possible so as to reduce the branching complexity of the unit. Unit testing when combined with test-driven development (TDD) makes it a powerful tool. Unit testing can be done in two subgroups –
- Sociable unit testing involves testing the behavior of the module by observing changes in their state.
- Solitary unit testing observes the interactions and collaborations between objects and their dependencies.
But unit testing doesn’t completely fit the bill since its complexity increases with the decrease in service size.
- Integration testing – An integration test exercises communication paths through the subsystem to find any incorrect assumptions that each module might have about interacting with its peers.
Integration testing helps verify the communication path and interactions between the components so as to detect interface defects. It is done by collecting microservices together and verifying whether they collaborate as intended to achieve a bigger business logic. It also helps test the communication path through a subsystem for checking any incorrect assumptions about each microservice.
In integration testing, it’s important to remember the end goal which is to aim for basic success and error paths through the integration module.
- Component testing – After executing unit tests, the next step is to test the microservice or the component itself. A component is an independent and well-defined part of a larger system.
Component tests are implemented in isolation and within each microservice’s code repository. Since a typical application will have numerous microservices, so to test a single microservice/component in isolation, we need to mock other microservices. This sort of isolation testing using test doubles helps avoid any complex behavior they might exert in execution.
Simply put, a major benefit of component testing is that it allows you to test microservices in isolation. This makes it easier, quicker, cheaper, and more reliable. But a drawback of component testing is that the microservice may pass the test in isolation, but the final application may fail in production.
- Contract testing – When a consumer couples to the interface of a component to make use of its behavior, a contract is formed. The component, in this case, is the microservice and the interface is the API exposed by a service.
Through a contract, a consumer and component exchange input and output data structures, performance, and concurrency characteristics. In contract testing, we write an independent test suit to verify individual contracts.
- End-to-end testing – In end-to-end testing, the intention is to verify that the system as a whole meets the business goals. The focus is less on the component architecture and more on the end result.
While writing an end-to-end test suite, it’s better to follow some basic guidelines like writing as few end-to-end tests as possible, focusing on personas and user journeys, relying on infrastructure as code for repeatability, and making test data independent.
- Performance testing – These strategies tend to be more complex than other testing strategies simply because of the high number of supporting resources and moving parts involved. Performance testing should help you determine how an application performs in different situations by finding bottlenecks as usage scales.
These days companies like Spotify, Netflix, Amazon, Uber, etc. have moved to microservice architecture. As adoption grows, QA becomes crucial for organizations to derive the full value from microservices. Ultimately, microservices will drive an overhaul of your application but that will only happen once you revamp your approach to QA and software testing.