Hong Le

Hong Le

Engineering Manager
Le Do

Le Do

Engineering Manager

Welcome back to Testing in Microservices 101!

In our first two lessons–err, part 1–we covered the differences between testing microservices verses monolith applications. We then went over some of the challenges unique to the architecture.

Today, we are getting into the nitty-gritty and answering: What factors should you consider when testing in microservices? AND what tests and tools are helpful to test in microservices?

So grab your notebooks, you might want to take some notes!

 

Lesson 3: Important Factors to Consider When Testing in Microservices

Now that you know the differences and challenges, we have a few more things for you to keep in mind when developing your testing strategy:

  • Contract Documentation – teams should work together during the design phase to create the API contract documentation. This agreement covers how each API service is designed.
  • Integration Testing – these tests will ensure that services continue to work well when they are integrated together.
  • Performance Testing – breaking an application up into many different services can lead to issues in performance. Make sure that performance testing is executed as soon as possible to prevent these issues.
  • Technology Stack –  since each service in a microservice architecture can be written in a different coding language, it is important to determine the right automation framework based on languages used.

 

Lesson 4: Microservices Tests and Tools

For our final lesson, let’s dive into microservices-specific tests and helpful tools. In addition to understanding traditional tests needed for a monolith application — think unit tests, component tests, etc.  — microservices testers must be able to perform contract testing and integration testing. These tests ensure that the various services are able to communicate and deliver outcomes as expected.

 

Integration Contract Testing

This type of test is carried out using a test double that replicates a service. This test is documented and periodically verified with the real services to ensure that there are no changes to the service that is exposed. This test prepares your team to perform the real iteration tests later. All your team will need to do is change the fake API to a real API and run the test again.

Tools: Leverage automation tools such as Katalon, Postman, SoapUI, or any in-house automation framework

 

Consumer-Driven Contract  Testing

As the name might suggest, consumer-driven contract tests replicate the way a consumer might use a service. This is done via consumer contracts in a mutually agreed schema and language.

Tools: Dredd – a language-agnostic command-line tool for validating API description document against backend implementation of the API. (Used for Provider site), Node.js consumer-contracts, Pacto (for consumer site)

 

Integration Testing – Internal:

As previously mentioned, when building complex functionality between services, you will often have to integrate with other services. This type of testing tests the data passed between two integrated services within your system.

Tools: Katalon, Postman, SoapUI, or any in-house framework was developed by your team.

 

Integration Testing – External:

These tests test data shared between services that are integrated with other external or third-party services

Tools: The tools for this test are a bit tricky as they depend on which type of services are integrated.

However, here are a few common tools to get you started:

  • Hoverfly – simulates API latency or failure when required by writing custom scripts in the language of your choice.
  • For messaging solutions, we use Apache Qpid for embedded AMQP or many of the commercial offerings offer a ‘mock’ mode like AWS SQS. OR there are open source options like FakeSQS, a lightweight server that mocks the Amazon SQS API.
  • Apache Qpid makes messaging tools that speak AMQP and support many languages and platforms. AMQP is an open internet protocol for reliably sending and receiving messages. It makes it possible for everyone to build a diverse, coherent messaging ecosystem.

 

Congratulations, you have officially completed the crash course in microservices testing!

For your final exam, you will be implementing what you have learned to develop a testing strategy for your microservices platform.

Ready for the advanced course? Partner with the experts at KMS to develop a testing strategy for your microservices platform. Check out our testing services and microservices offerings to learn more.


Leave a comment