Mock Turtle Soup

The big idea is "messaging"

I've been fretting over why so many smart people don't quite get what we've been trying to express with Mock Objects, and why we as a group think it matters. There's an experience we haven't been getting across properly. I think the step that's missing is the extent to which we use the Tell, Don't Ask pattern.

We pass behaviour in, rather than extracting state from an object. Really we do. In fact, the whole thing started at a session of the London Architects' Group when John Nolan asked what would happen if there were no getters. Combine that with Remove Duplication and Express Intent, and you have a very clean and flexible code base. Unfortunately, with everyone else using Java Beans and .Net properties, you also have a very unusual code base which might explain our difficulties.

The style we've developed concentrates on what objects say to each other, rather than how their state changes. Many people think that this locks down the test code because you're tracking its implementation, but that's less true if you can specify the conversation at the right level. If you tell the Agent to Purchase a Quantity at a Price, that's both more meaningful than telling it to Commit an Integer with a Decimal, and more flexible when it turns out that the price includes a currency.

The key for me was when Joe Walnes came up with the radical notion of "Don't mock types you don't own". This means: stop jumping through hoops to work with closed-world libraries, use the tests to discover your objects and what they say to each other. Don't just take my word that this is a good way to think about code, see Alan Kay's posting to the Squeak list

The big idea is "messaging" — that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word — ma — for "that which is in between" — perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.

As a community, we were diverted by an attempt to mock out the whole of the java libraries. Now that feels both overambitious and pointless. Apart from the scale, many of the stadard libraries do not mock well because their interactions are too complex, JDBC for example. Now we've got over that, and with jmock almost ready which will avoid the need to pre-build mocks, perhaps we can get back to the important stuff.

I've been translated!

Arton has translated my artice on writing test-driven JDBC into Japanese

Thanks

Don't buy bean bags

Some managemers seem to think that using bean bags in your office space will make their people more creative and inventive. I just heard a great story, at one level of indirection, from one of the original Smalltalk crew at Xerox PARC -- the archetypal bean bag institution.

It seems that they introduced bean bags because the people there were so argumentative that the only way anyone could get their point across was if they made it just too much trouble for the others to leap up and interrupt. They introduced bean bags to inhibit discussion, not facilitate it.

It's such a good story, I hope it's true.

Postscript. As always, Dilbert seems to be following me around.