Testing at MACH Speed: M is for Microservices

As the M in the MACH framework acronym, understanding the role that Microservices play is critical to understanding how to test them during development as well as during End-to-End testing. Think of microservices like individual Lego bricks that, on their own, don’t do much. But, when they are combined, they can build anything.
lego bricks

Dial M for Microservices!

Ok, so that doesn’t quite have the same hook as Alfred Hitchcock’s 1954 murder mystery thriller. But testing microservices can be a bit of a mystery from the retail QA perspective.

As the M in the MACH framework acronym, understanding the role that Microservices play is critical to understanding how to test them during development as well as during End-to-End testing. Just as the name implies, Microservices are small, independent services that can be coded, tested, and released on their own.

You may also read the term “composable eCommerce” and think, “Is this the same thing as microservices?” Here is the answer; kinda! One analogy I love to use when thinking about testing microservices involves Lego bricks. Think of microservices like individual Lego bricks that, on their own, don’t do much. But, when they are combined, they can build anything. A Composable eCommerce solution is where you can decide which bricks you want to build yourself vs. the bricks you rather buy from someone else to snap onto your bricks.

testing microservices
Build your own bricks, purchase other bricks, and voila! You built a whole composable house!

As a quick aside, it’s typically hard to discuss Microservices without mentioning Application Programming Interfaces, but for this blog series, I’m going to keep them separate.

Single Concern Microservices

Red Hat, in their excellent blog post on microservice design patterns, calls out five patterns you want to be sure to follow when migrating to microservices. The biggest one for me is that your microservice needs to be “single concern.” That is, your service does one thing and one thing only. This is a bit of a shift from classic, monolith-style eCommerce applications where everything is tied together in such a way that if one part fails, everything fails. With microservices, if an individual service fails, the other services remain available and functioning…but only if they are designed to do one “thing” and one thing only. IBM calls this microservice design pattern “limiting the blast radius” when a microservice fails.

It is very, very tempting to try and reduce the number of services by combining like services together, especially after you see just how many services your site will need! But it is critical when starting out to keep your microservices “small” from a functionality standpoint and separated from each other. My next post on APIs will get into how the services can be separated and still work together.

The Requirement-Gathering Process

As the business analysts start to gather the business requirements that the developers will turn into microservices, we in QA can help the requirement-gathering process in a couple of different ways:

  1. By supplying our current test cases
    • These cases should be mapped to the microservices being created.
  2. By providing the existing site’s baseline performance measurements
    • The microservice-based site will need to meet or exceed these baselines.

From a QA point of view, we want to work with both the developers and business analysts to be sure these questions are answered and documented as we start to move from designing the microservices to transitioning to how our APIs will use them:

  • What does this microservice do?
  • What data does this microservice need?
  • What rules do the data for the microservice need to follow?
  • How can the data be corrected if there is an error?
  • How fast will it take the microservice to return its results?
  • How many requests can the microservice handle at once?
  • How will the microservice interact with the other microservices?
  • How will the microservice interact with the user?

Here’s an example from a retail transformation – The customer enters their address information. You may have two different microservices working with the customer’s address information:

  1. The first microservice will validate that the customer’s address is correct against a 3rd party address validation database.
  2. The second microservice will send the validated customer address (passed from the first microservice) to compute the sales tax for the order.

With the information from the design phase in hand, you can start building your initial tests. This is when we will move to the A in MACH – APIs. Check out Part 2 of this blog series!