A key benefit to a microservices architecture is the ability to develop, test and deploy in isolation to other services. It seems paradoxical then, that for us, microservices slowed our software testing down. Instead of taking 3 days to test it was now stretching into 4 weeks. Factors such as uncertainty around boundaries, changing API contracts, configuration nightmares and scaling test environments all played a part. But that only told part of the story.
To test microservices we needed a different mentality, a different way of thinking. One that was founded within the context in which we were working. Part of the answer was to apply critical thinking to the problem, asking; "what are the desired outcomes of testing?” and "where is the greatest risk?"
We avoided the assumption that more testing equals better. After all, every test has a cost, and we wanted tests that offer the most value. But we didn't do this alone. In fact, it could be argued that the biggest benefit of microservices has been to increase collaboration between testers and developers.
This talk bases itself on a case study on a fintech who ventured down the microservices path and how a testing strategy was developed throughout the rapid growth of microservices. It describes the challenges encountered, the strategies we developed and lessons learned.
Join me for a 'warts and all' talk about testing microservices and pick up some lessons learned that perhaps will help you avoid some of the traps we fell into.