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.
Fredrik Wendt says:
I really see it as “as you work your way through /managers/ down to /worker/ classes”, you move from mocking to classical style.
2013-04-10, 13:40Ian Fairman says:
I like London School TDD – it feels more like a proper framework for emergent design than Classic TDD, although I imagine, as Fredrik says, you won’t use one style exclusively.
My nagging concern is that, once I’ve written my tests, they always look quite trivial. I feel with Classic TDD that I treat the class under test as a black box, whereas with London School I end up taking more of a white box view. I wonder what I am really testing.
2013-04-10, 15:37holger krekel says:
Co-incidences 🙂 Am on the travel for giving a two-day in-house course on testing (using pytest) and a major part of the exercises is going to cover and discuss mocks. I tend to discourage people from using mocking as much as possible. Testing collaborations can be an exception i guess.
Looking forward to more insightful posts 🙂
2013-04-10, 18:23Machiel says:
I often don’t use Mocks but Stubs (using Mocking tools). In my experience tying your test to the exact calls in your code, makes them rigid and refactoring hard.
The reason to use Mocks is for design, the test can then really drive your design process. The essential consequence that everyone misses is that the test should be removed when you’re done.
2013-04-14, 05:59Emily Bache says:
Thankyou for your comments!
Fredrik – I agree you could use both styles in the same system, depending on context. Would like a better elaboration of what you see as a “worker” class vs a “manager” class
Ian – I think I’ll be taking up issues around white/black box more in the third article in this series I’m planning.
Holger – sounds like you’re doing classic TDD then 🙂
Machiel – If you’re using tests purely as a design tool and they give no regression protection then you could remove them I guess. I don’t see many expert London School practitioners removing all their tests afterwards, although I think they may prune more than classic TDDers. Not sure on that point.
2013-04-19, 07:02Emily Bache says:
Fredrik – does this article describe what you mean by managers & workers? He calls them “Sergeant” and “Private” methods:
http://feelings-erased.blogspot.se/2013/01/single-method-perspective-vs-single.html
Interesting article, in any case
2013-05-02, 07:50