[
https://issues.apache.org/jira/browse/KAFKA-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767899#comment-16767899
]
Guozhang Wang commented on KAFKA-6460:
--------------------------------------
Ah yes, that's a good point.
Thinking about this again, how about injecting the mocking logic into
{{TopologyTestDriver}} so that users do not need to make any code changes,
while the cost is to push the code complexity burden on Streams (i.e. inside
{{TopologyTestDriver}}). More specifically:
When {{TopologyTestDriver}} takes in the {{InternalTopologyBuilder}} as
parameter, loop over its {{stateFactories}} and {{globalStateBuilders}} map,
and replace each entry (StateStoreFactory's embedded {{StoreBuilder}}, and
{{StoreBuilder}} respectively) with the mock store builder by checking its
type, e.g. {{KeyValueStoreBuilder}} -> {{MockKeyValueStoreBuilder}}, etc.
So that for both PAPI and DSL, user code does not need to change at all:
1) PAPI users in production / testing code:
{{Topology#addStateStore(Stores.keyValueStoreBuilder(...))}}.
2) DSL users in production code, without materialization spec: {{aggregate()}}
2) DSL users in production code, with materialization spec:
{{aggregate(Materialized)}}
Then the only additional API we need is to allow users to check the number of
function calls for a given store with
{{TopologyTestDriver#putEntries(storeName)}}. WDYT?
> Add mocks for state stores used in Streams unit testing
> -------------------------------------------------------
>
> Key: KAFKA-6460
> URL: https://issues.apache.org/jira/browse/KAFKA-6460
> Project: Kafka
> Issue Type: Improvement
> Components: streams, unit tests
> Reporter: Guozhang Wang
> Assignee: Yishun Guan
> Priority: Major
> Labels: newbie++
>
> We'd like to use mocks for different types of state stores: kv, window,
> session that can be used to record the number of expected put / get calls
> used in the DSL operator unit testing. This involves implementing the two
> interfaces {{StoreSupplier}} and {{StoreBuilder}} that can return a object
> created from, say, EasyMock, and the object can then be set up with the
> expected calls.
> In addition, we should also add a mock record collector which can be returned
> from the mock processor context so that with logging enabled store, users can
> also validate if the changes have been forwarded to the changelog as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
