Creating a microservices ecosystem is definitely the way of the future and allows for faster development and expansion of complex and varying features to be developed without the need of expensive and time-consuming maintenance of a bigger monolithic system. This development approach is not without its challenges, though, especially on the testing side. While the ambitions of a microservices architecture are normally around creating interdependent systems, testing can seldom live in isolation and needs to somehow retain an understanding of that bigger picture which makes it such a tricky thing to balance.
Think of building a puzzle
A good analogy to use for this is that of building a puzzle. Building a big puzzle takes a lot of time and effort to get right, though in the end with a clear plan and visual of what the final outcome should look like, you will eventually get it completed. With a microservices architecture, teams are essentially building that same puzzle, except they only get to see parts of it and might not always have all the ideas of what that final picture will look like.
Those individual pieces can certainly be built a lot quicker, but there is always uncertainty that they might not fit together as well as you hoped or that some of the shared pieces used to make the parts come together has created waste and lead to a puzzle that doesn’t look as well as intended.
So, are microservices still worth the quality risk then, given these scenarios? Absolutely, the benefits of speed and scalability are certainly with it and while the technical challenges are there they can be overcome.
Knowing your piece of the puzzle
Going back to our puzzle analogy, you might not have the big picture of what the puzzle looks like but if everyone knows exactly what their pieces need to look like and the shapes of the pieces that are required, you can still build them and know they will fit together. What this does require though is teams knowing their pieces of the puzzle and how they connect together a lot more intimately than before.
Essentially, for microservices testing to work teams need to consider the following:
- Have a clearly laid out architecture and set of standards to follow. While microservices offer a lot of freedom and flexibility for teams, there needs to be clear guidelines for how software communicates with each other and what it need to look like. If these are not well defined early, teams are going to waste a lot of effort in mitigating change and the inevitable integration effects that will need to be fixed. Part of making this work is also design test frameworks that are suited for scale and not constrained to the products under test.
- Know your dependencies and how to mock them. If you can test the basic inputs and outputs of how your services interact with others and these are well defined, it should be easy to test and automate these upfront. Yes, there is always a chance dependencies change, but if you build the appropriate contract tests with the respective APIs, you will be able to pick these up and prevent your software from deploying and be able to rectify these issues before going live. Following a model of independent test design is ideal here.
- Test where the logic is. Too much effort is often spent trying to do expensive integration tests, when the majority of the logic is sitting in code than can easily be taken care of at a unit test level. While there is always a need for integration testing, if you have a high level of coverage at a code level, the reliance on expensive integration tests is reduced.
- Automate everything. While this is a pipe dream for many. If you have the above three things in order, automation is actually quite easy. And if you’re testing closer to your code, also a lot faster to write and execute in your pipelines. Don’t use manual testing as an excuse to test your different systems end to end. If you’ve done your homework with the things above, you’ve created a road-map for easier automation that doesn’t compromise your overall system quality.
Grow your technical capabilities
If there is perhaps one thing that should be clear with the above approaches though it’s that test engineers need to plugged into the architectural details of how the system is developed and be technical enough to test the required architecture. If teams are looking to innovative, scale and deliver software faster without compromising their quality, they have no option but to develop technical testers that are capable of designing software and writing code to make the parts work together from a quality perspective.