Is there any difference between ".andReturn (...). AnyTimes ()" and ".andStubReturn (...)" in EasyMock?

Question

This post states that there is a difference (see SnoopyMe's comment) and that the two options can be used interchangeably. The EasyMock documentation does not mention any differences.

Is there any difference, practically or semantically? If so, when is it more appropriate to use one over the other?

EDIT:

The following test shows that there is a difference, at least when used with a strict layout:

@Test public void testTestMe() { Bar bar = createStrictMock(Bar.class); expect(bar.doBar()).andReturn(1).anyTimes(); expect(bar.doOtherBar()).andReturn(2).once(); replay(bar); Foo foo = new Foo(bar); foo.testMe(); verify(bar); } @Test public void testTestMeAgain() { Bar bar = createStrictMock(Bar.class); expect(bar.doBar()).andStubReturn(1); expect(bar.doOtherBar()).andReturn(2).once(); replay(bar); Foo foo = new Foo(bar); foo.testMe(); verify(bar); } public class Foo { private final Bar _bar; public Foo(Bar bar) { _bar = bar; } public void testMe() { _bar.doBar(); _bar.doOtherBar(); _bar.doBar(); } } 

andReturn (...). anyTimes () still validates the order that strict layout does during validation. andStubReturn (...), however, does not.

However, it is still not clear to me if this is the only difference or what is the difference in semantics. For example, is anyTimes () the same as stubReturn () for a regular (non-strict) layout?

Answer 1

The difference is tiny in terms of results. For a normal layout, this is the same. However, for a strict layout, the blank can be called up at any time without any respect for the order. anyTimes can be called at any time, but only in recorded order.

This difference is caused by semantic difference. A stub is something that can be called up at any time during the test, and you don't care when and how many times. In fact, most mocking methods are stubs in general.

Then anyTimes means you don't care. But in fact, I never use it. When I do the test, I know what will happen. My methods are always obscured or expected to be called the exact amount of time.