Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Mocking framework


Copy link to this message
-
Re: Mocking framework
On Thu, Oct 27, 2011 at 10:55 AM, Drew Farris <[EMAIL PROTECTED]> wrote:

> I agree in principle without having reviewed the tests accompanying
> ACCUMULO-53.
>
> 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.
>
> Drew
>
> On Thu, Oct 27, 2011 at 12:49 PM, Jesse Yates <[EMAIL PROTECTED]>
> wrote:
> > 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
> of
> > the architecture that we are interested in testing, helping to isolate
> and
> > ensure that we are really fixing problems in the code.
> >
> > So, I would like to propose adding the following test-time dependencies
> for
> > 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
> EasyMock
> > 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
> patch
> > 'java_ACCUMULO-53_v2.patch' on ACCUMULO-53.
> >
> > What does everyone think?
> >
> > Thanks!
> > --Jesse
> >
> > -------------------
> > Jesse Yates
> > 240-888-2200
> > @jesse_yates
> >
>

--
-------------------
Jesse Yates
240-888-2200
@jesse_yates
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB