Get started Bring yourself up to speed with our introductory content.

Key steps to save time when testing microservices

Microservices are a hot dev choice, but how do they fit into a software tester's job? Expert Matt Heusser explains how they speed up testing time and support continuous delivery.

A microservices approach to software development results in small, reusable components that teams can use to assemble...

software. Microservices enable code repurposing (to be adaptive), which allows teams to rebuild web applications for iOS or Android or anything else quickly and cheaply.

But there's a different aspect of microservices worth exploring -- how they can be testable, lead to less regressions in production and enable continuous delivery. A smart microservices approach can lead to higher code quality for free. Here's why the approach works so well and also how to get there.

Contrasting sample applications

The web applications of the previous decade connected to a database, executed a query to get the information that should appear on the page and printed the page. Some applications combined all the pages into a single compiled file. Complex applications had spillover, where a change in one area of the code could break something somewhere else in the application, which required retesting everything between releases.

A web application that uses microservices is built differently. Instead of a large compiled application, there might be a smaller outer 'shell' that takes web request. The shell serves up the basic dimensions of the page and declares major sections -- global navigation/header, "more items to consider," "recommendations for you," "new for you," and so on -- with a footer at the bottom. Each of these services "serve up" two things -- some JavaScript to format the section and a call to an inner service.

These inner services provide plain text lists – such as books, employees and posts. Sprinkle on a few services to get a book's description, price and image, and services for functions like login, search and tag, and suddenly building new features out of services is more like sewing a patchwork quilt and less like hand knitting.

This approach can lead to testing microservices and regression testing.

Advantages for regression testing

Imagine a login function that needs a wording change on error. You don't want a hacker to realize they have the correct account, so you make the invalid password and the invalid user ID message match. Both of these could probably be changed, recompiled and shipped.

If the service is truly isolated, you test the service, put the service in staging, test again and ship the code to production. If it is not, then the code requires a full compile. Full compiles and cutover are generally expensive. Teams are more likely to make several changes at a time, which introduces spillover, leading to regression and testable activity.

Truly isolated components greatly reduce, if not eliminate, spillover.

Consider our e-commerce example again. When "new for you" fails, it simply takes up zero space. The outer shell adjusts and prints the rest of the elements. While this won't work for login, search or other core services, it does mean that pages that consist of multiple services can suffer outages with less impact.

A pattern for testing microservices

In Alistair Cockburn's hexagonal architecture, services are the line that extends from the application to the database. This makes it possible to do two kinds of tests.

First, isolate the service, send it various types of data and compare the expected results to the actual results. Ideally, record the interactions to allow automatic checking. When that step is complete, it is possible to record those interactions and place them in a mock, or stub service. Then the entire application can be exercised quickly, standing up against the mock. The advantage here is that teams that change the service and see the checks passing can deploy the service without retesting the entire application.

If the service continues to provide results that are acceptable to the application, then new versions can be swapped out on demand. These sorts of cutovers take tenths of a second, not seconds or minutes. They affect the user less while enabling faster releases with less defects escaping, and less impact when they do.

Alistair Cockburn's hexagonal architecture

Moving toward microservices

The challenge with moving to microservices is typically "where to start?" It is tempting to propose a complete website redesign or to create a "microservices" team or department. Doing a reboot, however, means the existing website still needs to be maintained. If the website is ever finished, it will likely either be based on an out-of-date specification, be over-budget due to changes or both. The change also creates two levels of staff -- the new programmers and the maintainers -- and implies an adversarial relationship between the two. If the new programmers ever finish, the future of the maintainers is uncertain.

You can think of microservices as little slices of a business process. A microservice at an insurance company, for example, might tell if a member has coverage of a certain type on a certain date. Another might return a list of claims for a given member or group over a date range. Those sorts of lookups already exist, and could be copied, pasted and reinvented over and over again in reports, applications, on the website in claim lookup and perhaps in the data warehouse.

To get started, identify a logical service and an owner. This service should be the one most likely to be reused. For claims, that might be the electronic data interchange team or a reporting team. Start with a guide to services at the company, have the team create the service and add it to a public repository -- a sort of phone book for services.

Over time, other teams can adjust their code to use the service.

In the final analysis

While the examples started with a website, microservices can really be used to capture any business process. They reduce regression testing because they are isolated, which means they make just the service testable, not the entire end-to-end system. Testing microservices is also easier to due to the input-expected response nature of the services. Companies that move to a microservices approach will find they are identifying and eliminating redundant code -- code that is just different enough that one version must have some sort of error.

It is a long journey, but testing microservices has the potential to directly improve software quality while reducing testing time. It is a testable potential worth investigating.

Next Steps

At the intersection of containers and microservices is DevOps

Testing microservices can be a bit easier if you sign on to SOA

Are you an expert on SOA and microservices? Find out.

This was last published in August 2016

Dig Deeper on Agile DevOps



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Where is your development organization on the journey to microservices?
I suppose that we’re lucky in that we have two major initiatives going that make the move to microservices easier - a planned rewrite of two of our primary legacy applications and a major push to move our apps and services to AWS.
Microservices change the landscape for all levels of testing. There’s an excellent slide deck out on Martin Fowler’s site about testing strategies in a microservice architecture: