Testing Microservices

[Martin]

Has anyone experienced testing within a microservice architecture?

How have people gone about testing microservices in isolation and integrated?

Any help or useful references appreciated please?

Thanks
Martin

[Paul]

Hey Martin, I came across microservices as a new topic when researching new areas of focus for TEST Huddle content. One name that cropped up quite a bit was Martin Fowler. Maybe you’re already aware of him?

http://martinfowler.com/microservices/

http://martinfowler.com/articles/microservice-testing/

May be useful!

[Andrei]

Hi Martin,

What kind of service are you using and what level of interaction do you plan to use? (Unit (white-box) or Service Integration (Black box))? Depending on the specifics of your project, there can be various approaches.
As above, Martin Fowler is a great point to start reading about it!

[Ronan Healy]

I think @amcharrett is fairly knowledgeable on this so might be able to help.

[Michael]

Hi, Martin…

A little context would help here. What’s the confusion you’re experiencing? What problem are you trying to solve?

—Michael B.

[Martin]

@paul-madden, @andreicontan @michaelabolton

Thanks for the help. So yes, it is all new to us, which is the first problem. So Paul, yes I need to spend more time looking through the Martin Fowler resources as that seems to be the initial point of understanding.

Andrei, very good questions, I am still in the process of understanding and defining the interactions myself.

Perhaps if I was to try and give a bit more context, as suggested by Michael, it would help answers so these questions.

So we have an existing architecture, which is service/component based, and we are moving over to a microservice architecture so that we can provide our customers with a cloud based offering. To test the functionality provided by the microservice in isolation, that being defined as a vertical slice through the system, we will be using REST API calls. This is not entirely new to us as we have gradually been moving over to supporting REST as an alternative to SOAP even with our current architecture. One specific question I do have here, which may fall under a different thread but would be useful to ask nevertheless, is whether any of you have every auto-generated REST API calls from a YAML spec which development are currently defining using Swagger? Development are already generating code from the spec and technical authors will inevitably look at using for the same purpose. so I was thinking why not testers, at least to get some basic coverage in place. If anyone has done this or has any ideas regarding tools or approaches, that would be of great value?

So in terms of the architecture itself, I would imagine that we would have 2 main levels of testing here. Initially at the first level, we will be working on a single microservice and therefore focused on the kind of tests we can perform on that microservice in isolation. We will be integrating with a Platform as a service (PaaS) which will have (hopefully!) the necessary capabilities to start and manage lightweight Docker containers hosting a microservice. Therefore we will be interested in testing quality attributes of that microservice. We will be interested in testing performance aspects such as startup times and also scalability, aiming to ensure that if a microservice is stopped and restarted it comes up quickly and it’s integrity is preserved.

Secondly, and a bit further down the line, we will need to integrate the microservices. Whilst microservices are designed to provide their own slice of functionality, there will be certain levels of integration tests that we will need to define. So imagine we have 10-15 microservices which provide the complete set of functionality which define the system, Certain microservices may be interested in certain information contained with another microservice. Since they can’t talk to each other directly, an internal messaging service will be used to push out events of interest between the microservices. This raises some interesting questions from an integration perspective. These shared concepts need to be eventually consistent between collaborating components, so we need to have tests to check this. Then there is the whole area of recovery. A microservice should continue to work even if another collaborative microservice is not available, and when it recovers it needs to be in a consistent state. We will also have attached resources, which will typically be databases or messaging systems but could be something more sophisticated such as a caching system, event stream, document repository etc.

Hopefully this has put some more context, at least from a high level perspective. Overtime I will hopefully be able to be more specific!
Let me know if you have any thoughts or ideas, I’m sure they will be of great value to me and my colleagues.

Thanks
Martin

[Andrei]

Hey Martin,

I work with similar application, also based on microservices. I’ll try to describe my approach in 2 sections:

On the technical solutions:
ApiGee offers some API Test Templates based on Swagger-based implementations.. You can find more here. http://apigee.com/about/blog/developer/swagger-test-templates-test-your-apis
If talking about Java, my favourite approach is building a test automation framework based on Jersey (Java library) which enables you to define a very flexible test automation solution. I also use it in my test automation classes, see github solution here (https://github.com/andreicontan/TestAutomation/tree/master/openweathermap-java-api-master)
If .NET I successfully use RestSharp (no demo project to show here, yet).

THe test approach:
Along with Jersey based framework I use TestNG whcih enables me to structure the tests based on specific needs.
When implementing tests, I start bottom-up. Meaning I test individual microservices using mocking and moving forward with acceptance integration tests in which we target the communication between 2 or more microservices.

Make sure to pay attention to ESB as well…during performance tests we found out that ESB was a bottle neck when processing high volume transactions.
We also built an architectural map describing the interaction between microservices, enabling us from a testing perspective to know what kind of tests to trigger based on specific changes on one or more components of the system.

Hope it gives you a better view on how to approach your test strategy.
BEst,
Andrei

[Author]

Posts