Whitepaper: Testing Microservices

Microservices adoption is on the rise. Don’t let the struggles of understanding how to test them get in the way of your quest to build complex systems.

Learn how to simplify testing of microservices architectures.


Download the whitepaper to discover the key to taking control of microservices testing: creating successful automated tests.

Learn about:
  • The struggles associated with understanding how to test microservices
  • The two patterns microservices follow when interacting with each other
  • Considerations for configuring test environments
  • Mainstream knowledge about how to build and maintain different kinds of tests is still in its infancy.
  • In some respects, testing a microservices application is no different than testing an application built using any other architecture.
  • Microservices use well-known technologies such as REST or queues for which the industry already has well-established testing tools and best practices.
  • The unique challenge with microservices is the sheer number of services that make up an application along with the dependencies between the services.
  • In addition, each microservice still needs to function properly even when the other microservices they depend on are unavailable or responding improperly.

Orchestration pattern

  • A microservice using orchestration will make one or more explicit calls to external services or dependencies.
  • The calls typically use a synchronous request-response flow and will often access REST-based services.
  • If the services need to be called in a specific order, calls to a subsequent service are not made until a response is received for a call to a prior service.
  • Because one service explicitly calls another, they are tightly coupled.

Associated challenges:

  • The Portfolio microservice has dependencies on the Accounts and Quotes microservices, which need to be deployed in the test environment along with the Portfolio microservice, but the team that is building the Portfolio microservice may not be the team building the other two microservices.
  • The Quotes service has a dependency on a 3rd-party service to retrieve real-time stock prices, and the data returned by that service is always changing. To make a stable test for the Portfolio service, the data returned by the Quotes microservice needs to be constant.
  • Unexpected behaviors of the Portfolio service need to be tested, such as when the Accounts and/or Quotes services are unavailable, respond slowly, or respond with unexpected data. It is important to be able to make those services respond with different kinds of unexpected behavior to validate that the Portfolio microservice handles the error conditions properly.

Recommended solutions: A service virtualization solution such as Parasoft Virtualize.

Reactive (choreography) pattern
  • One of the primary goals of a microservices architecture is to create independent components.
  • As a result, deploying, scaling, and updating the services will be easier.
  • This goal is not completely realized, however, when using the orchestration pattern because individual microservices have direct dependencies on other microservices.
  • A way to solve this is to use the choreography pattern, also known as “reactive” or “event-driven” microservices.
  • In this pattern, microservices do not directly reference each other. Instead, they push messages onto event streams to which other microservices have subscribed.

Associated challenges:

  • The asynchronous communication in this type of architecture introduces the benefit that the services are highly decoupled from each other – instances of each service can get replaced, redeployed, or scaled without the other microservices caring about them.
  • The tradeoff is that the asynchronous nature of the events makes it harder to understand how the system will execute and what the flow of events will be. Depending on the order or kind of events that are produced, the system could behave in unexpected ways. This is known as emergent behavior, an inherent challenge in the development and testing of choreographed microservices.

There are different asynchronous messaging patterns that fall under the broader category of event-driven microservices.

  1. Asynchronous command calls

    Recommended solutions:

    Parasoft SOAtest

    RabbitMQ custom transport from Parasoft Marketplace

  2. Event firehose

    Recommended solutions:

    Parasoft SOAtest

    Kafka custom transport from the Parasoft Marketplace             
  • Many microservice teams have adopted a CI/CD process for building, testing and deploying containerized microservices to automate the process and decrease the risks associated with deploying updates.
  • The messaging patterns and associated test patterns discussed in this paper are not new, but the need to use these patterns has grown significantly as microservices become more common and more applications adopt a microservices paradigm.

About Parasoft

Parasoft helps organizations continuously deliver quality software with its market-proven, integrated suite of automated software testing tools. Supporting the embedded, enterprise, and IoT markets, Parasoft’s technologies reduce the time, effort, and cost of delivering secure, reliable, and compliant software by integrating everything from deep code analysis and unit testing to web UI and API testing, plus service virtualization and complete code coverage, into the delivery pipeline. Bringing all this together, Parasoft’s award winning reporting and analytics dashboard delivers a centralized view of quality enabling organizations to deliver with confidence and succeed in today’s most strategic ecosystems and development initiatives — security, safety-critical, Agile, DevOps, and continuous testing.