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>
