Thanks for the feedback Matthias! The reason I proposed the extension of MockProcessorContext was more to do with the internals of the class (MockRecordMetadata, CapturedPunctuator and CapturedForward).
However, I do see your point, I would then think to split MockProcessorContext and MockFixedKeyProcessorContext, some of the internal classes should also be extracted i.e. MockRecordMetadata, CapturedPunctuator and probably a new CapturedFixedKeyForward. Let me know what you think! Regards, Shashwat Pandey On Mon, Mar 11, 2024 at 10:09 PM Matthias J. Sax <mj...@apache.org> wrote: > Thanks for the KIP Shashwat. Closing this testing gap is great! It did > come up a few time already... > > One question: why do you propose to `extend MockProcessorContext`? > > Given how the actual runtime context classes are setup, it seems that > the regular context and fixed-key-context are distinct, and thus I > believe both mock-context classes should be distinct, too? > > What I mean is that FixedKeyProcessorContext does not extend > ProcessorContext. Both classes have a common parent ProcessINGContext > (note the very similar but different names), but they are "siblings" > only, so why make the mock processor a parent-child relationship? > > It seems better to do > > public class MockFixedKeyProcessorContext<KForward, VForward> > implements FixedKeyProcessorContext<KForward, VForward>, > RecordCollector.Supplier > > > Of course, if there is code we can share between both mock-context we > should so this, but it should not leak into the public API? > > > -Matthias > > > > On 3/11/24 5:21 PM, Shashwat Pandey wrote: > > Hi everyone, > > > > I would like to start the discussion on > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1027%3A+Add+MockFixedKeyProcessorContext > > > > This adds MockFixedKeyProcessorContext to the Kafka Streams Test Utils > > library. > > > > Regards, > > Shashwat Pandey > > >
