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”:http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html 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”:http://joe.truemesh.com/blog/ 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”:http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
bq. 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”:www.jmock.org almost ready which will avoid the need to pre-build mocks, perhaps we can get back to the important stuff.