cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: EasyMock best practices
Date Mon, 20 Jun 2011 02:26:22 GMT
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.    


> Thanks,
>   - Dennis
Daniel Kulp
Talend -

View raw message