#3 EasyMock should behave normally after a failure

[Henri Tremblay]

Submitted by Mike Dunbar

Running the main method of this class demonstrates the issue.

---

public class DemoEasyMockIssue {
public static interface TheInterface {
public String foo();
public String bar();
}

public static void main(String[] args) {
TheInterface mock =
createMock(TheInterface.class);
expect(mock.foo()).andReturn("foo").anyTimes();
replay(mock);
mock.foo();
System.out.println("Calling foo works as "+
"anticipated, before the call to bar.");

  try {
     mock.bar();
  }
  catch(AssertionError error) {
     System.out.println("Calling bar gives the " + 
        "anticipated error: " + error);
  }

  try {
     mock.foo();
  }
  catch(AssertionError error) {
     System.out.println("Calling foo again after" +   
        "bar gives an unanticipated error: " +  
        error);
  }

}
}

---

To me it seems like a bug that mocks report expected calls as unexpected, after any call to an unexpected method. At the very least, the error message is misleading because it only says that the expected
method call was unexpected. I'm sure it's probably the case that you would normally be calling the unexpected method as part of a test, fail before you ever try and make a subsequent call on the expected method, and this wouldn't matter. But due to one of the automated testing tools that we use this isn't desirable. I would like subsequent calls to expected methods to behave based on the recording.

Is this reasonable?

[Virtualwarp]

I have an issue when testing code that has a try-finally block and I think this is the same issue as reported here.

When I run a test for code containing a try-finally block, easymock reports the last unexpected call. If an expectation in the try-block fails, the expectation in the finally-block will also fail. Since the last failure is reported, the original reason for the failure is no longer visible.

Example:

mock.write(2);
mock.close();
replay();

try {
mock.write(1);
} finally {
mock.close();
}

verify();

[Henri Tremblay]

Hi. No it's not the same thing. You've encounter a standard issue with finally. If the finally clause throws an exception, you loose the original one. And yes, that can bring to a nasty debugging session.

However, I think EasyMock can workaround that by knowing it is currently throwing an exception and so rethrowing it in the finally. I'll enter a new requested feature about it (but I don't think it will be solve really soon)