Enabling Microservice Success

Chapter 10. Getting Value from Testing

Testing helps you to build the right thing, and it tells you when something has stopped working the way it should. But if you take the wrong approach to testing, your tests can slow down every release because they take so long to run, and they still may not catch the real problems. Even worse, you can spend far more time making changes to your tests than to the code itself!

Testing is of course a huge topic. My main focus in this chapter is to talk about it in the context of moving to a microservice architecture.¹ Testing microservices is not the same as testing a monolith, and I want to explain why.

The most important change is about mindset and organizational structure. Treating testing as a separate activity, done by a separate team as a prerelease activity, has long been considered a bad idea. With microservices, you simply cannot afford to do this. You need testing to be done throughout the route to production, by your engineering team, whether you have specialist QA people on that team or not.

Quick automated unit tests give a lot of value with a microservice architecture, but running end-to-end tests in production with good monitoring is often a more effective approach than trying to run similar end-to-end tests in preproduction environments, which can turn into fixture maintenance hell. Manual testing as part of each release needs to be kept to a minimum: it simply takes too long and is too error prone and inconsistent when you move ...