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
