EasyMock best practices

[Dennis Sosnoski <dm...@sosnoski.com>]

I've been dealing with a lot of EasyMock unit tests in the WS-RM
restructuring, and found what I'd consider to be a design flaw with
EasyMock (or a flaw in the way the unit tests are using it, however you
want to see it). When you use EasyMock.expect(...) by default EasyMock
requires one and only one call to the method. The problem I see with
this is that it's testing based on an implementation, not on
functionality, and changes which use different code to provide the same
functionality break the unit tests.

My suggestion is to *always* use the qualifier .anyTimes() with
EasyMock.expect(), unless there's a specific reason you believe there
should be a specific number of calls to the method.

Does that make sense to everyone, or am I missing something here? I'm
changing over some of the existing WS-RM unit tests to take this
approach, so if anyone objects I'd like to know before I get too far
down this road.

Thanks,

  - Dennis

-- 

Dennis M. Sosnoski
Java SOA and Web Services Consulting <http://www.sosnoski.com/consult.html>
Axis2/CXF/Metro SOA and Web Services Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>

Re: EasyMock best practices

[Daniel Kulp <dk...@apache.org>]

On Sunday, June 19, 2011 9:13:54 AM Dennis Sosnoski wrote:
> I've been dealing with a lot of EasyMock unit tests in the WS-RM
> restructuring, and found what I'd consider to be a design flaw with
> EasyMock (or a flaw in the way the unit tests are using it, however you
> want to see it). When you use EasyMock.expect(...) by default EasyMock
> requires one and only one call to the method. The problem I see with
> this is that it's testing based on an implementation, not on
> functionality, and changes which use different code to provide the same
> functionality break the unit tests.
> 
> My suggestion is to *always* use the qualifier .anyTimes() with
> EasyMock.expect(), unless there's a specific reason you believe there
> should be a specific number of calls to the method.
> 
> Does that make sense to everyone, or am I missing something here? I'm
> changing over some of the existing WS-RM unit tests to take this
> approach, so if anyone objects I'd like to know before I get too far
> down this road.


I had this same conversation with a co-worker last week.  :-)     The "Easy" 
mocks really do make code refactoring much harder than it should be.   I tend 
to start doing the same "anyTimes()" thing as well.  Thus, I'm completely OK 
with that idea.    

Dan


> 
> Thanks,
> 
>   - Dennis
-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com