Microservices through the eye of the QA expert – testing microservices

And it’s really worth it to work on that. TSH’s Head of QA Dawid Krala and Head of Node.js Adam Polak explain why improvements in testing microservices is the low hanging fruit you can pick up to vastly improve your architecture and the whole software development process.

Testing microservices – challenge for all, problem for many

Today however, we would like to focus on just one issue raised by the report – testing microservices.

According to our report, the topic of maintenance and debugging microservices is the least enjoyed part of working with this architecture, scoring an average of 3.4 out of 5:

The Software House’s CTO confirms these findings in the report, saying:

“For the last 2 or 3 years, more and more clients have approached us and asked us for help because their in-house development teams lost control over microservice-based projects.”

This loss of control can be attributed mostly to scalability issues that stem from poor handling of maintenance and QA from the start of the project – something quite difficult to make up for later in the project.

As for debugging itself, the good news is that most developers use some debugging solutions. The bad news is that as many as 27% of them use ONLY logs. It is also by far the most popular overall method of debugging:

Asto Digital’s CTO Thomas Boltze is highly critical of logs-only approach, saying that it is consistent with the easy-to-observe pattern of building microservices first and for getting about the “consequences of going all-in with the microservices, and getting the scope of a service right”.

That’s why our report has to say. And what about TSH’s Head of QA Dawid Krala and Head of Node.js Adam Polak? Let’s find out 🙂

Unique QA challenges for microservices architecture

Dawid believes that when it comes to microservices, there are several challenges that need to be managed by a well-defined QA strategy:

The first challenge is to define the microservice architecture in a project. Before we start development, we should think about:

• services communication, 
• cyclic dependencies of each service, 
• distributed logging which may influence debugging, 
• security of each service,
• data consistency / synchronization, 
• performance tracing,
• failovers of each service.

Then, once the development is in progress, we may have an issue with microservices integration testing and debugging of such services.

When it comes to the environments and deployments, the DevOps team should be involved. They need to ensure the security of such an environment. Also, they need to have a well-defined monitoring of such systems.

When working in a team, we should also remember that communication is the key. Each developer can work on a separate microservice, hence good coordination of such work is the key factor to success.

The simple solution to overcome such challenges is to have a well thought-out QA strategy for such projects. Teams working with microservices should automatically apply an approach of writing and maintaining documentation for each service. When it comes to testing strategy, the good approach may be the “testing trophy”: start from static tests, then write optimal (not too many) unit tests.

Developers should focus on integration tests to ensure that services communicate without any issues. The contract tests should be considered as an important part of their testing.

Testing microservices trends

Dawid believes that microservices greatly influenced the way QA specialists work on a daily basis and that without incorporating these changes, you can’t have a good microservices testing strategy:

The Microservices architecture definitely influenced the work of QA specialists. Because microservices are deployed typically in environments that use containers like Docker, this forces all QAs to learn how they can set up such a test environment.

When we talk about testing, they should apply a ‘shift-left testing approach’, which means they should focus more on unit and integration tests rather than end-to-end testing. The unit test and the integration test capability, of course, requires programming skills.

QAs should focus on contract tests as an important part of their daily activities in such projects. In order to do that, they should be able to read service documentation (ex. Swagger). 

Security and performance of such services are also important and should be on the list of testing activities of QA engineers. They also should be able to monitor such microservices (for example, with the use of the Prometheus–Grafana combination).

Strategy for testing microservices

According to Dawid, the right strategy for testing microservices should incorporate a mix of functional tests and non-functional testing and tools that can be specific to each project, as well as some standard best practices:

The most important point is to define a thought out-testing strategy (the right level of functional tests as well as non-functional testing: failovers, recovery, performance, security). It’s also vital to adhere to standardized development practices. The role of DevOps in the team can’t be overstated to keep the maintenance and debugging in check at each and every stage of the project.

Testing microservices – best practices

Let’s now take a look at the best practices:

There are a couple of rules:

1. Define and run the right level of tests:
2. 1. static code tests,
   2. unit tests to validate each function of a microservice,
   3. component tests to validate service itself,
   4. integration tests, especially contract tests.
3. Verify the right security of services.
4. Verify performance of the system.
5. Test how your entire system behaves when one of the services is down (for example, using the Chaos Monkey tool).
6. Test if your system is discovered automatically when it’s up,

Let’s check out the best microservices testing tools!

Testing microservices – tools

There are many tools that can help you with your testing microservices strategy. TSH’s Adam Polak lists some of the best options out there:

• Chaos Monkey – the previously mentioned resiliency tool from Netflix will help you with managing and preventing the consequences of random services instance failure and test the behavior of each service.
• JMeter, Locust, K6 – some of the most common performance and load testing tools and other tools like these.
• Pact – to facilitate your contract testing.
• Mocha, Jest, Supertest or any other popular integration and unit testing tool and microservices testing framework.

Onto the summary.

Testing microservices – what’s the deal with it?

The QA strategy for your microservices-based project should be decided on a project-by-project basis. Regardless of that, it should always be incorporated from the very start of the work to prevent serious scalability issues. Many developers seem to be uncomfortable with this particular aspect of microservices and rush to build. 

But the truth is that with the right strategy and tools, it’s quite easy and the only challenge is to actually care about it enough. And giving the topic the care it deserves is the best first step to mastering it and creating scalable and efficient applications with microservices.

Be sure to read the entire State of the Microservices 2020 report to find out even more about the best practices for building with microservices in 2020, including:

• the programming language developers choose to use most often,
• the way developers deploy microservices to maximize their benefits,
• the impact of the serverless approach to software architecture on microservices,
• continuous delivery and integration,
• trends in the consumption of APIs,
• micro frontends,
• and more!

Best of luck with microservices testing!