jMock ordering

In case anyone (i.e. me next week) needs to specify explicit method ordering in jMock, here it is. This code specifies the order of a chain of method calls (it came from testing a wire protocol implementation - don't ask...), rather than just expecting all calls to come after a single call. In particular note the ordering of the id() and after() calls, once again IntelliJ saves the day.

Mock mock = mock(RedstripeSocketTransport.class);
mock.expects(once()).method(METHOD_OPEN).id("CallOpen");
mock.expects(once()).method(METHOD_WRITE).with(eq(seededRequest))
    .after("CallOpen").will(returnValue("foo")).id("CallWrite");  
mock.expects(once()).method(METHOD_READ).after("CallWrite")
    .will(returnValue(seededResponse)).id("CallRead");
mock.expects(once()).method(METHOD_CLOSE).after("CallRead");
return (RedstripeSocketTransport) mock.proxy();

Note that that write() does not actually return a value in the production code, it's in the post to help me remember ;) Apologies to Andrew if he's posted this already, I thought he had, but google does not know about it...

Vlad has made a good suggestion in the comments, that statements have the method name given to them as ID by default. I'd seen this as an error message but wasn't sure what it meant.

Closures for Java

Danny's been talking about Closures in Java. We did a similar thing in JRDF for testing.

AssertThrows.assertThrows(RuntimeException.class, new AssertThrows.Block() {
    public void execute() throws Throwable {
      somethingThatIExpectWillThrowAnException();
    }
});

All in all the syntax is ugly and nowhere near as neat as Ruby's, however such constructs can significantly cut back on duplication.

Up yours

Now this is priceless: Mac OSX. Mac OSX Up Yours T-Shirt.