[
https://issues.apache.org/jira/browse/KAFKA-9088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988149#comment-16988149
]
Sophie Blee-Goldman commented on KAFKA-9088:
--------------------------------------------
I'm also fine with going ahead with the EasyMock "experiment" but just to lay
out my personal experience as well, EasyMock has not had a very good
time-saved:time-wasted ratio. In addition to the "obnoxious" amount of code
overhead in setting up a new test, the heavy use of EasyMock in testing core
Streams infrastructure makes any change in behavior a nightmare to deal with.On
the surface, it's just an annoyance and waste of time when a minor change or
even simple refactoring breaks half the tests in a single module (due to the
specific expectations for method invocations).
But slight annoyances aside, I think that reflects a much deeper issue which
is: how do you know when your refactoring has actually broken something? When
dealing with core infrastructure (as in KIP-429 for example) there are often no
behavioral differences until you reach the system-wide level, and therefore all
the testing ends up being "does this method call this specific other method,
exactly this number of times" which is less of an actual test and more like
writing the same code in a slightly different format. It's not helpful, and
when it breaks it's not because of a bug or resulting error, it's because the
code it's "testing" is not literally the same code it was before. You then
"fix" the test by changing the EasyMock expectations to reflect the new code,
but again, that's not really a test. Worse yet, once in a while a test _did_
break because of a an actual problem, but because you've just had to patch up
100 EasyMocked unit tests, you almost surely don't think twice about it and
just rework the EasyMock code until it passes.
Anyways, there's my long rant about EasyMock. I think it's not always the right
tool for the job, but that said I haven't personally dealt with any tests that
had to use one of the mock internal ProcessorContexts so I can't say for sure
that it is/isn't the right choice here.
I guess I wanted to say, we should think carefully going forward about when
(and why) to use EasyMock and not just default to it because it's "easy" – just
because it's easy doesn't mean it's right ;) (not to mention, it's not always
even that "easy")
> 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)
