Testable architecture of micro-services


There are mutliple ways to test code: unit tests /e2e / manual testing /..

I’m developing a project that it’s implementation details changes very quickly (and sometimes the core functions as well).

Some of our microservers talk to each other directly while some others communicate using events like kafka.


When I create an e2e test (for the backend image only), before each test(s), I build the docker image of my micro service and run it again on (each) test.

I find it really hard to set up this kind of e2e test for a micro service that directly talks to other microservices (sending get/post/.. requests).

As a result, I also build/pull the other images and run them before each tests as well. But it’s not that easy because you can end up implementing a version of docker-compose in you tests infrastructure.

I would like to minimize the amount of errors that can come from other services and test a specific microservice.

Possible solution:

Changing the microservices architecture.

When ever it is possible, a micro service will communicate with others using events. So in the tests, we only need to setup a kafka and the microservice that we try to test.

I only though of this solution from testing perspective and not from “what is best”, for example, it’s faster to communicate without kafka.


What are the pros and cons of my proposal? From your experience, is it maintainable?

Go to Source
Author: Stav Alfi