Saying nothing is not the same as saying "nothing"
The DynaMock mock objects API allowed programmers to specify that a method had no arguments by not specifying anything about expected arguments at all. This confused users of the library. The new version of the API, now being developed under the jMock banner, forces users to specify expected arguments in detail. Users prefer the clarity, despite the extra typing, because it helps them avoid subtle errors.
I recently answered a question on the Mock Objects mailing list. A user of the library had thought that passing no explicit argument constraints to an expectation set a mock object up to expect any arguments. In fact, it sets the mock object up to expect no arguments.
mock.expectAndReturn( "methodName", result );
Is the same as:
mock.expectAndReturn( "methodName", NO_ARGS, result );
And different from:
mock.expectAndReturn( "methodName", ANY_ARGS, result );
In a spooky example of synchronicity, I had been hacking on the implementation of that syntactic sugar the previous afternoon and had come to the conclusion to remove it because (a) it was an extra set of overloaded methods that needed to be maintained and I'm lazy and (b) it was confusing because it hid the intent of the programmer instead of expressing it clearly. The user request just confirmed my opinion that this particular piece of syntactic sugar is a mistake.
The new "hot mock" API will require explicit specification of argument constraints when setting up expectations. I showed an example to people at a recent XtC session.
mock.method("methodName").with(eq(arg1),same(arg2)).willReturn(result)
.expectOnce();
I expected complaints from people who didn't like the extra typing required, but to my surprise, they actually preferred code with explicit constraints over the existing syntactic sugar. So, users get more readable tests and the jMock team gets fewer overloaded methods to maintain. It's a win-win situation.
I've just realised that the definition of 'nothing' has tripped me up before. The concept of nothingness seems to be more complex than is immediately obvious. Something to keep in mind in future designs.