3 Tools for Testing Microservices
3 Tools for Testing Microservices
There are types of testing that are unique to microservices. Learn about three tools that can enable microservice testing to maintain and improve functionality.
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
Testing microservices can be tricky. In this post, I’ll cover some tools that can help you do so. But first, how exactly should you test your microservices?
This is a special case of a broader question: how should you test your software? The answer I’ve come up with over the past few years is that there are four types of testing, and you need to use each one at different points in a product’s lifecycle:
- Understanding Users: using methods like A/B testing and usability testing, your goal is to discover what you users need and what problems they are having.
- Correct Functionality: using manual testing, code review and the like, your goal is to ensure your software is correct, that it matches its specification.
- Preventing Change: using unit tests and other automated tests, your goal is to prevent unwanted changes from being introduced into your code.
- Understanding Runtime Behavior: by stress testing, load testing and monitoring of your production system, your goal is to discover what operational problems your software has.
You can watch a recording of my talk at the PyCon conference to get the full explanation of these types of testing and when you apply each. This testing model is the result of personal experiences and failures outside the realm of microservices. But since the model is generic it can be applied to microservices as well, so in this post, I’d like to share three tools that can enable these necessary forms of testing.
Preventing Change With Hoverfly
A microservice will rarely stand alone: it will rely on cloud infrastructure like databases, as well as on other microservices. These dependencies will present an API, which, by its nature, is expected to be stable. This then is the realm of automated tests, whose goal is to prevent change; you want to assure that your interactions with other APIs don’t change unexpectedly when you change your code. Hoverfly is a tool for simulating APIs and simulating latency and failures in your APIs. This allows you to write automated tests that can run independently of other microservices.
Understanding Runtime Behavior With Lyft Envoy and Ambassador
When you’re running many microservices you want to expose them all easily, and one way to do that is with an API gateway. Ambassador is an API gateway that builds on Lyft’s Envoy proxy and communication bus, allowing microservices to easily register their public API endpoint. Once you’re running your microservices in production you want to understand how they’re behaving. Envoy provides a variety of ways to get statistics about traffic and monitor messages; see Ambassador’s documentation for details on how to get this information with Ambassador.
Correct Functionality With Telepresence
If you want to make sure your software is behaving correctly, or you need to debug a complex problem, there’s no substitute for human judgment; only a person can tell you whether something is correct behavior. Telepresence allows you to swap out running code in a staging Kubernetes or OpenShift cluster, replacing it with code running on your laptop. That means you can manually try out your code in a realistic environment, or step through your code with a debugger as you reproduce the problem in a real environment.
Tools can help you test your software, but in the end, the most important decision you’ll make is how to test your software. Watch my talk for some suggestions on how to get started, and then go take a look at Hoverfly, Ambassador, and Telepresence.
Published at DZone with permission of Itamar Turner-Trauring . See the original article here.
Opinions expressed by DZone contributors are their own.