Recently I’ve become quite interested in the London School of TDD. I blogged before about my experiences doing Luca Minudel’s exercises, in my post “SOLID Principles and TDD“. Since I wrote that, I’ve read Steve Freeman and Nat Pryce’s book “Growing Object Oriented Software, Guided by Tests” and practiced doing some code katas in this style. In my experience there is a lot of confusion around how to use Mocks, and I found it enlightening to see how the people who invented the technique actually use them.
My current thinking is that there are at least these two areas where London School TDD differs from Classic TDD:
- Outside-In development with Double-Loop TDD
- “Tell, Don’t Ask” Object Oriented Design
London School practitioners use Mock Objects as a tool for achieving both. Let’s look a little more about what Mocks are for.
Verifying behaviour
A test case often has three parts: “Arrange – Act – Assert”. In the second edition of his book The Art of Unit Testing, Roy Osherove points out that in the “Assert” part of a test there are three ways to ensure the class you’re testing is behaving correctly. After “Arrange” and “Act”, you can:
- Check the return value, or an exception.
- Check the state of the object, or the state of a collaborator.
- Check the object correctly interacts with a collaborator.
This last form of assertion is generally done using a Mock Object. With an ordinary Mock you set it up in advance to check for a particular interaction, with a Spy, you check after the fact. In either case, you’re asserting an interaction happens correctly. You’re checking a particular object received a particular method call, and you can be more or less strict about the precise details of arguments and numbers of invocations.
In Classic TDD, whenever possible you check a return value or exception. If you’re testing a void method, then you usually take the second option and check state. Only if the other options are really unattractive do you ever turn to using a mock. It’s the last choice.
With London School TDD, the option of using a mock is chosen much more often. You’ll still check return values or object states where that makes sense, but using a mock is often an attractive option. This is because using a mock helps you to both develop your system Outside-In, and to design your objects in an “Tell, Don’t Ask” manner.
Mocks used badly
I think one reason that using a mock object is often the last choice in classic TDD, is because it’s so easy to get into trouble when using them. You should be using mocks to help you improve your design, but all too often the design is bad, and the mocks are either hiding that, or getting in the way. I sometimes see tests with an enormous “Arrange” part, specifying half a dozen different mocks before they’ve even started calling any functionality. Such a test is bound to be brittle, and could hinder your refactoring to a better design.
The article “Eliminate most Mocks from Unit Tests” by Arlo Belshee gives an example of using a mock to compensate for bad design, and he has several other articles in the series. I think Arlo is largely criticising poor use of mocks actually, rather than London School TDD itself.
It seems to me that you can abuse any technique, and Object Oriented Design is actually very difficult. Steve Freeman has said “No tool nor technique can survive inadequately trained developers“. London School TDD is a design technique that is not easy to master. I talk more about this in my next posts “Outside-In Development with Double Loop TDD“, and “Tell, Don’t Ask” Object Oriented Design.
