On Thu, Oct 27, 2011 at 10:55 AM, Drew Farris <[EMAIL PROTECTED]> wrote:
> I agree in principle without having reviewed the tests accompanying
> I've used EasyMock in the past and have been very happy with the
> ability to programatically mock implementations of interfaces, define
> test input and assert a proper sequence of calls, and output. In
> general I think mock object testing is a useful tool, especially in
> cases where the existing interface implementations have heavyweight
> external dependencies, such as for mocking JDBC result sets or
> portions of the Hadoop framework. I've used mock objects to write unit
> tests for mappers and reducers by mocking out the hadoop context,
> counters, etc. Arguably this would be have been better achieved with
> MRUnit, which wasn't on my radar at the time.
> I found that I didn't have to jump through hoops to make code
> testable. Private methods could really be private instead of protected
> or public in order to facilitate testing.
The comment about testing private methods was only a comment on the power of
the framework, not on what should be done. IMHO you shouldn't be testing
private methods w/o a very good reason.
> I also appreciate the
> ability to not only assert return values, but assert a series of
> method calls and side effects.
> The danger with this is only testing in isolation using mocks -- If
> the mocks don't follow the contract or conventions the implementations
> the tests are useless or deceptive. Implementation class behavior can
> change in ways that are invisible from an api perspective, so it's
> important that these sorts of changes be reflected adequately by the
> mocks themselves.
Of course there is also the case where you end up just checking to make sure
the object under test calls a series of methods on your mock - not a really
informative test and bring of the correct interface issue you mentioned.
> Coupled with adequate integration tests this danger
> is minimized. Generally I think the tradeoff in increased testability
> makes up for these drawbacks.
+1 for good integration tests; they tend to mitigate that issue.
> On Thu, Oct 27, 2011 at 12:49 PM, Jesse Yates <[EMAIL PROTECTED]>
> > Hi all,
> > Currently Accumulo doesn't have any mocking framework. However, in some
> > recent work (ACCUMULO-53) doing good testing was greatly facilitated by
> > adding in a mocking framework. They make it easy to only test the piece
> > the architecture that we are interested in testing, helping to isolate
> > ensure that we are really fixing problems in the code.
> > So, I would like to propose adding the following test-time dependencies
> > testing:
> > EasyMock (http://easymock.org/)
> > This is a really popular mocking framework for java and is really easy to
> > use. I've rarely run into a situation that wasn't covered with what
> > does.
> > PowerMock (http://code.google.com/p/powermock/)
> > This is the utility to cover what other mocking frameworks (including
> > Mockito) can't do - capturing creation of objects (new Whatever(...)) and
> > returning mocks instead, mocking static calls, mocking standard java lib
> > calls, and accessing private methods/fields.
> > This combination has proven to be incredibly effective and easy to use in
> > the past, allowing for a really comprehensive testing suite.
> > If you want to see an example of this stuff in action, check out the
> > 'java_ACCUMULO-53_v2.patch' on ACCUMULO-53.
> > What does everyone think?
> > Thanks!
> > --Jesse
> > -------------------
> > Jesse Yates
> > 240-888-2200
> > @jesse_yates