Sweet! I think this pretty much wraps up all the discussion points.
I'll update the KIP with all the relevant aspects we discussed and call for
a vote.
I'll also comment on the TopologyTestDriver ticket noting this modular test
strategy.
Thanks, everyone.
-John
On Fri, Mar 9, 2018 at 10:57 AM,
Hey John,
Re: Mock Processor Context:
That's a good point, I'm convinced that we should keep them as two classes.
Re: test-utils module:
I think I agree with your proposed changes, in fact in order to not scatter
the test classes in two places maybe it's better to move all of them to the
new m
Hi Guozhang and Bill,
I'll summarize what I'm currently thinking in light of all the discussion:
Mock Processor Context:
===
Here's how I see the use cases for the two mocks differing:
1. o.a.k.test.MPC: Crafted for testing Streams use cases. Implements
AbstractProcessorContext,
Hmm.. it seems to be a general issue then, since we were planning to also
replace the KStreamTestDriver and ProcessorTopologyTestDriver with the new
TopologyTestDriver soon, so if the argument that testing dependency could
still cause circular dependencies holds it means we cannot do that as well.
John,
Sorry for the delayed response. Thanks for the KIP, I'm +1 on it, and I
don't have any further comments on the KIP itself aside from the comments
that others have raised.
Regarding the existing MockProcessorContext and its removal in favor of the
one added from this KIP, I'm actually in fa
I think what you're suggesting is to:
1. compile the main streams code, but not the tests
2. compile test-utils (and compile and run the test-utils tests)
3. compile and run the streams tests
This works in theory, since the test-utils depends on the main streams
code, but not the streams tests. an
Thanks, Matthias,
1. I can move it into the o.a.k.streams.processor package; that makes sense.
2. I'm expecting most users to use in-memory state stores, so they won't
need a state directory. In the "real" code path, the stateDir is extracted
from the config
by org.apache.kafka.streams.processor.
Actually, replacing the MockProcessorContext in o.a.k.test could be a bit
tricky, since it would make the "streams" module depend on
"streams:test-utils", but "streams:test-utils" already depends on "streams".
At first glance, it seems like the options are:
1. leave the two separate implementation
Thanks for the review, Guozhang,
In response:
1. I missed that! I'll look into it and update the KIP.
2. I was planning to use the real implementation, since folks might
register some metrics in the processors and want to verify the values that
get recorded. If the concern is about initializing a
Hello John,
Thanks for the KIP. I made a pass over the wiki page and here are some
comments:
1. Meta-comment: there is an internal class MockProcessorContext under the
o.a.k.test package, which should be replaced as part of this KIP.
2. In @Override StreamsMetrics metrics(), will you return a fu
On Wed, Mar 7, 2018 at 8:03 PM, John Roesler wrote:
> Thanks Ted,
>
> Sure thing; I updated the example code in the KIP with a little snippet.
>
> -John
>
> On Wed, Mar 7, 2018 at 7:18 PM, Ted Yu wrote:
>
>> Looks good.
>>
>> See if you can add punctuator into the sample code.
>>
>> On Wed, Mar
Dear Kafka community,
I am proposing KIP-267 to augment the public Streams test utils API.
The goal is to simplify testing of Kafka Streams applications.
Please find details in the
wiki:https://cwiki.apache.org/confluence/display/KAFKA/KIP-267%3A+Add+Processor+Unit+Test+Support+to+Kafka+Streams+T
12 matches
Mail list logo
