Consider removing @DirtiesContext necessity for @EmbeddedKafka

Thank you for the careful and detailed explanation, I found my solution with the third proposition.

For future reference, here’s what I ended up doing:

1. I created a JUnit 5 extension that initializes the kafka broker. This initialization is done only once per test suite, and only if at least one test uses the extension, so that if we launch tests that do not require a spring context we do not create the kafka broker for nothing:

public class KafkaBrokerExtension implements BeforeAllCallback {

  private static EmbeddedKafkaBroker embeddedKafkaBroker;

  @Override
  public void beforeAll(ExtensionContext extensionContext) {
    if (embeddedKafkaBroker == null) {
      embeddedKafkaBroker = buildEmbeddedKafkaBroker();
    }
  }

  private static EmbeddedKafkaBroker buildEmbeddedKafkaBroker() {
    EmbeddedKafkaBroker embeddedKafkaBroker = new EmbeddedKafkaBroker(1)
        .brokerProperties(Map.of("listeners", "PLAINTEXT://localhost:9092"));
    embeddedKafkaBroker.afterPropertiesSet();
    return embeddedKafkaBroker;
  }
}

1. I also created a TestExecutionListener using the selfsame extension (see https://junit.org/junit5/docs/current/user-guide/#launcher-api-listeners-custom) that destroys the broker, if it exists, when all tests are executed:

public class KafkaBrokerExtension implements TestExecutionListener {
 ...  
  @Override
  public void testPlanExecutionFinished(TestPlan testPlan) {
    KafkaBrokerExtension.getEmbeddedKafkaBroker().ifPresent(EmbeddedKafkaBroker::destroy);
  }
}

It’s not a perfect solution (I don’t like static initializers) but we improved the build time by 20%.

Well, then extension you suggest is not consistent: it may start the broker in a first test, but it is not going to be stopped until the end of the plan. When only that first class is interested in such a broker. I know that my testPlanExecutionStarted() is too drastic, but at least it is very clean what is going on around the whole test plan.

This Embedded Kafka was really designed for individual test cases, for different Kafka environment, different number of brokers etc. What you are talking about is more like a single Kafka instance which is better to manage outside of the project test plan. Your suggestion is just a bit of an anti-pattern for Unit paradigms.