[
https://issues.apache.org/jira/browse/KAFKA-9088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987478#comment-16987478
]
John Roesler commented on KAFKA-9088:
-------------------------------------
Hey all,
I can see I've missed some discussions here. I've read over the ticket and also
looked over the highlights of the PR.
I'm afraid I really don't think that EasyMock is going to be a good approach
here. It's a great library for when you need to mock things that are painful to
implement, or when you need to play through different specific scenarios in
different tests.
But at the same time, it can be a major pain to work with. Tracing the
execution with the debugger is virtually impossible: as soon as you
accidentally descend into the mock, you're deep into Java black magic. Figuring
out when to set up expectations and when to replay them is deeply confusing.
And paradoxically, just setting up a mock to consistently behave in a "normal"
way takes an obnoxious amount of code.
My experience says that if what you're trying to mock has a relatively simple
interface and state space, then just go ahead and implement a "manually mocked"
implementation. Only reach for EasyMock when this basic approach is too
difficult for some reason.
If I understand this ticket, the motivation was _only_ that there exist two
similar classes in the Apache codebase, not that there is anything actually
wrong with either of them. In that case, we shouldn't switch to EasyMock. We
should just consolidate the implementations... Or not! I didn't see any actual
justification for _why_ it's a problem to have two similar classes, and if
consolidating them results in a lot of difficulty, or a lot of extra code, then
consolidating is the wrong thing to do.
Either way, Just looking at the PR, it seems that this _consolidation_ strategy
results in adding _double_ the lines of code that we're removing.
I know that this must have taken a ton of work, so I've been sitting here
trying to thing of something else to say, but it really feels like we need to
go back to the drawing board here and ask ourselves what we're trying to
accomplish, and at what cost.
Thanks,
John
> Consolidate InternalMockProcessorContext and MockInternalProcessorContext
> -------------------------------------------------------------------------
>
> Key: KAFKA-9088
> URL: https://issues.apache.org/jira/browse/KAFKA-9088
> Project: Kafka
> Issue Type: Improvement
> Components: streams, unit tests
> Reporter: Bruno Cadonna
> Assignee: Pierangelo Di Pilato
> Priority: Minor
> Labels: newbie
>
> Currently, we have two mocks for the {{InternalProcessorContext}}. The goal
> of this ticket is to merge both into one mock or replace it with an
> {{EasyMock}} mock.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
