[TeeWEE]

This is useful too but expensive.

Test containers provide a middle ground.

For example we have pure unit tests. But also some tests that boot up Postgres. Test the db migration and gives you a db to play with for your specific “unit” test test case.

No need for a complete environment with Kafka etc. It provides a cost effective stepping stone to what you describe.

What would be nice if test containers could create a complete environment, on the test machine and delete it again.

Still a deploy with some smoke tests on a real env are nice.

[AdrenalinMd]

It's not really a middle ground if you're not testing your service in the same conditions as in production environment.

If you're not testing integration with Kafka, and the producer, your service is still lacking integration tests.

Testing classes in isolation with testcontainer is fine. But I observed that with microservice architecture the line between E2E tests and integration tests are blurred.

Microservices can and should be tested from the client perspective.

[TeeWEE]

True but if you want to test every merge-request it becomes expensive.

We had a customer k8s cluster per feature branch with e2e testing.

A middle ground is testcontainers for feature branches, and the trunk branch a full e2e suite deployed to a live cluster...

[user_of_the_wek]

In my last project we used https://java.testcontainers.org/modules/kafka/ to start a small Kafka container. It's not the exactly like a production installation, but it goes a long way.