Hey Fabrizio, nice article, good job here!
But may be worth to fix few inconveniences about your definition of "mock".
When you are talking "DB, streams and other services are mocked" - and then you say that you can "mock" your database with test-containers, it feels like you don't really get what is "mocked". Because you don't mock the database, you just run the real database in a container. Same in the integration tests. You can find more info on how to actually mock the database interaction for example here: https://dev.to/techschoolguru/mock-db-for-testing-http-api-in-go-and-achieve-100-coverage-4pa9
And while microservices.io clearly says "A test suite that tests a service in isolation using test doubles for any services that it invokes.". Which is likely to mean other services are mocked - in your definition, but not DB to stream. And here is an easy explanation why it is so - in microservice world all microservices should have it's own databases and not share it with other services. So Database is a part of a service's context, therefore should not be mocked as it is a part of a component being tested. And when it comes to stream - it is just an easy way to emulate other services actions -> pass data from test to stream, and our testes service will get event from it, so you can think about stream more or less like about it's API actually, so it should not be fixed unless we are injecting all mocks on the app level throwing out all network communication.
Martin Fowler on the other hand considers two approaches here:
- first when you stub/mock everything on application level: injecting mocked dependencies in interface requirements of your app instead of real implementations. In such case you mock db and streams for real to speed up tests. But that means that you move component tests to unit tests level, and you should throw network communication away completely. So you will definitely not need docker containers and everything like that. This is just like unit tests, but the tests cases will be based on tested service's consumers scenarios.
- second when you stub mock other services on API level, so you run other services as mocks (you create http, grpc services that mock dependent services, or write/read streams as other services would do) and you leave DB and streams as is (you can run it using test-containers, docker-compose etc).
Anyway thank you for your article, it is much closer to the current view of testing pyramid, hope you will find some time to fix these parts, as it can be misunderstood especially by newbie testers :)
