Requirement of using @DirtiesContext with @EmbeddedKafka

[wagonli]

Hello,

I'd rather open a discussion instead of an issue yet :

I find the requirement of having to annotate our IT tests with @DirtiesContext in order to use the @EmbeddedKafka annotation a bit counterproductive. (as stated here in the documentation :
https://docs.spring.io/spring-kafka/reference/testing.html#embedded-broker-with-springjunitconfig-annotations

From my experience destroying and restoring a context is a very time consuming operation. Big projects with lots of tests usually chase down all the cases that meddles with spring context to keep them to an absolute minimum.

I understand that there is a current race condition between the Kafka server and Spring regarding the shutdown hook and the cleaning of kafka's temporary files but using @DirtiesContext is more like a very non performant workaround than an actual solution to this problem.

I don't really have a solution in mind given the current state of the code but I feel like the KafkaServer should be able to give us some kind of actionable handle to better coordinate shutdowns.

What do you think ?

[artembilan]

Take a look into that doc if global embedded Kafka is a solution for you:

Starting with version 3.0, the framework exposes a GlobalEmbeddedKafkaTestExecutionListener for the JUnit Platform; it is disabled by default. This requires JUnit Platform 1.8 or greater. The purpose of this listener is to start one global EmbeddedKafkaBroker for the whole test plan and stop it at the end of the plan. To enable this listener, and therefore have a single global embedded Kafka cluster for all the tests in the project, the spring.kafka.global.embedded.enabled property must be set to true via system properties or JUnit Platform configuration. In addition, these properties can be provided: