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 [email protected] http://dankulp.com/blog Talend - http://www.talend.com
