Big thanks for your feedback, Matthias — much appreciated ! MJS1: Regarding backward compatibility, another option could be to introduce a new class, "MultiPartitionTopologyTestDriver". This would allow us to keep the current behavior where input and output topics must be created before sending records. It would also avoid introducing a multi/active mode in the existing "TopologyTestDriver". The new class could coexist alongside TopologyTestDriver starting in Kafka 4.x (for example 4.3 or 4.4). TopologyTestDriver" could then be deprecated in Kafka 5, while MultiPartitionTopologyTestDriver would become the default and only driver in Kafka 6. In this new class, topics would be multi-partitioned by default, which would align with the intended behavior of a test driver for kafka.
MJS2: We agree that using ConsumerRecords-like semantics could be an interesting alternative for reading from multi-partition output topics — it’s closer to the Kafka consumer API and may feel more familiar. As you said, there are trade-offs: it could be more verbose for simple test scenarios, and we would need to decide whether to expose partition-level access directly. I do not think the second example here >> // Optional helper: read directly from a specific partition >> TestOutputTopic<String, String> partition1Topic = outputTopic.partition(1); >> List<TestRecord<String, String>> partition1Records = >> partition1Topic.readRecordsToList(); is really necessary when testing and reading results. With the default partitioner, the first example is sufficient and correct. Thank you for your help. Best regards, Adam, Julien, Sébastien and Marie-Laure
