Hi Matthias! Thanks for the note, and the kind sentiment.
We're always open to improvements like this, so your contribution would certainly be welcome. Just FYI, "public interface" changes need to go through the KIP process (see https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals ). You could of course, open an exploratory PR and ask here for comments before deciding if you want to make a KIP, if you prefer. Personally, I often find it clarifying to put together a PR concurrently with the KIP, because it helps to flush out any "devils in the details", and also can help the KIP discussion. Just wanted to make you aware of the process. I'm happy to help you navigate this process, by the way. Regarding the specific proposal, the number one question in my mind is compatibility... I.e., do we add new dependencies, or change dependencies, that may conflict with what's already on users' classpaths? Would the change result in any source-code or binary incompatibility with previous versions? Etc... you get the idea. We can make such changes, but it's a _lot_ easier to support doing it in a major release. Right now, that would be 3.0, which is not currently planned. We're currently working toward 2.5, and then 2.6, and so on, essentially waiting for a good reason to bump up to 3.0. All that said, EmbeddedKafkaCluster is an interesting case, because it's not actually a public API! When Bill wrote the book, he included it (I assume) because there was no other practical approach to testing available. However, since the publication, we have added an official integration testing framework called TopologyTestDriver. When people ask me for testing advice, I tell them: 1. Use TopologyTestDriver (for Streams testing) 2. If you need a "real" broker for your test, then set up a pre/post integration test hook to run Kafka independently (e.g., with Maven). 3. If that's not practical, then _copy_ EmbeddedKafkaCluster into your own project, don't depend on an internal test artifact. To me, this means that we essentially have free reign to make changes to EmbeddedKafkaCluster, since it _should_ only be used for internal testing. In that case, I would just evaluate the merits up bumping all the tests in Apache Kafka up to JUnit 5. Although that's not a public API, it might be a big enough change to the process to justify a design document and project-wide discussion. Well, I guess it turns out I had more to say than I initially thought... Sorry for rambling a bit. What are your thoughts? -John On Fri, Dec 6, 2019, at 07:05, Matthias Merdes wrote: > Hi all, > > when reading ‘Kafka Streams in Action’ I especially enjoyed the > thoughtful treatment of > mocking, unit, and integration tests. > Integration testing in the book (and in the Kafka codebase) is done > using the @ClassRule-annotated EmbeddedKafkaCluster. > JUnit 5 Jupiter replaced Rules with a different extension model. > So my proposal would be to support a JUnit 5 Extension in addition to > the JUnit 4 Rule for EmbeddedKafkaCluster > to enable ’native’ integration in JUnit 5-based projects. > Being a committer with the JUnit 5 team I would be happy to contribute > a PR for such an extension. > Please let me know if you are interested. > Cheers, > Matthias > > > > > > > > > > > Matthias Merdes > Senior Software Architect > > > > heidelpay GmbH > Vangerowstraße 18 > 69115 Heidelberg > ------------------------------------------------------------- > +49 6221 6471-692 > matthias.mer...@heidelpay.com > -------------------------------------------------------------- > > Geschäftsführer: Dipl. Vw. Mirko Hüllemann, > Tamara Huber, André Munk, Georg Schardt > Registergericht: AG Mannheim, HRB 337681 >
