The microservice testing blame game
When there's 20 microservices and an Acceptance Test fails, the blame game starts.
One microservice team pushes the blame onto the other team, and no one really knows who's responsible. Analyzing logs, debugging, a lot of emails sent back and forth between the teams. Finally, the issue is localized to one microservice team who caused the regression bug, they fix it, and hope that the Acceptance Test will now pass.
Is there a faster, more efficient way to pinpoint which microservice caused the regression bug?
Yes, there is: Component Testing. With Component Testing, each microservice would be tested in isolation of other microservices. Each microservice has its own pipeline with its Component Tests. It's only when the Component Tests pass for a microservice, that we'd build and publish its Docker Image, which will then be the candidate for running Acceptance Tests.
Thus, for Acceptance Testing, we only use Docker Images of microservices that successfully passed their own Component Testing.
This means, when a team introduces a regression bug that it can be caught by their own Component Tests in their own pipeline, and won't even reach the Acceptance Tests. So the team can solve the issue on their own without inter-team back-and-forth communication.
Thus, with Component Testing, we can test Components to ensure they work in isolation. This means that it's easier for a Microservice team to get faster feedback, rather than having to wait for a failing Acceptance Test.
Want to apply TDD in practice?
You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project, and get my feedback and answers to your questions. Access TDD in Legacy Code.