Today at the GOOSgaggle event in London, Brian Marick gave the presentation “I Think I Finally Understand Mocks”. Nat Pryce said that I was the person most likely to bother with entering the wireless key (64 character random code, they really do take their security seriously at Zuhlke), in order to blog in real time. In order not to disappoint Nat, here goes…
Marick started by saying that he was one of the reviewers of the original mock paper, and that he at that point completely misunderstood the idea and thought that the authors were reinventing test stubs. It wasn’t until four months ago, when he read Growing Object Oriented Software, that he really understood what the concept is all about. Marick said that “the point of mocks is illustrated by a photo of surgeon working on a cow. [You, the surgeon, work with a team and when] you explain what you want to do, reach out your hand and magically the tool you want appears in your hand”.
Demonstrating how he uses now mocks, Marick went through the design and implementation of a recent project with an exercise involving attendees pretending to be objects and mocks in four iterations. After that, he pointed out that he really designed the code in the test, rather than in the implementation. “This is just stenography”, said Marick pointing to the implementation.
There isn’t much more that happens in the implementation apart from what was in the test, and mocks allow us to describe the design in tests with less friction (note: this refers to the implementation of the object under test, not its dependent objects). Objects with complex dependencies require us to set up all those complicated dependencies in the test with classic TDD. This increases the clutter in the test. Using mocks allows us to avoid setting all that up in a test and describing the test (and design) more efficiently. Marick said that this benefit surprised him once he started using mocks properly. “Instead of giving the right time slice, mocks allow you to just give back a token representing a time slice,” said Marick, pointing how mocks facilitate outside-in design, “If it looks as if there is going to be some complicated work, I push the work away into a new object”.
“Doing top-down makes it much more likely that I’ll hit my destination”, said Marick, pointing out that there is no rational reason to choose top-down over bottom-up design, but from his experience the style of working with mocks leads to better design faster. “Things are flowing smoothly without a lot of friction.”, said Marick. Analysing the resulting code, Marick said that the objects ended up not doing much. He stressed out that conventional TDD makes him pile more and more code into a class or a method until it gets so big that “shame forces me to notice that these five methods are doing the same thing and pull them out. Things get big, then small, then big again”. “Mocking really encourages me to push”, said Marick, pointing out that with mocks he gets to smaller objects quicker, allowing him to “make decisions at the last responsible moments”.
Image credits:Interplast @ Flickr
|
|
I went into mock land a few years back and came back to classic state TDD precisely due to the realization that I was essentially implementing the production code twice.
I wonder if the following statement is true: mock-based testing drives initial design better at the expense of later ability to refactor.
My state-based tests have an arms-length relationship (or I like to think they do) with the implementation. Therefore I can change the implementation independently of the tests, as long as the module under consideration doesn’t change its contract.
Design By Contract became TDD (state-based). But the step from state-based to interaction-based TDD seems to me to be much more radical. I think interaction fans have the burden of explaining why we should effectively be writing our production code twice rather than running experiments at the contract boundary. After all, why not just drop the test and write your code once?
Steve, from my experience, mocks prevent later refactoring only if misused. When your mock objects describe exactly what the collaborators are doing, instead of how you collaborate with them, you bake in the implementation of dependent classes into tests. If the mocks just describe the collaboration without how it is implemented, this problem doesn’t come up. See also my earlier post about this
i was at the GOOSgaggle event too, i would agree with gojko here
steve said
“… due to the realization that I was essentially implementing the production code twice.”
if this is the case, it is a code smell, “test code mirrors production code” steve and nat talked about this at one of their, presentations several years ago, it basically means you havent distinguised bettween internal and peer objects. you essentially mocking internal objects.
Mocking is a useful technique but certainly not the holy grail.
I prefer using mocks in combination with a lot of mini integration tests (so state based verification instead of behaviour based verification) as ‘unit’ test mechanism.
They are a good tool in the toolbox but certainly not the only one.
I think what he discovered was Top-Down TDD + Test Doubles, which in this case was Top-Down + Mocks.
However, the same could be applied with Fakes/Stubs/Spies. When you’re going to be doing something complicated, you put that on another object and you check the interaction via a spy. Or when setting an expected return (i.e. using mocks as Stubs), then you can replace that with your hand-rolled stubs as well.
Sure it entails more work, but from my experience, changing the contracts is much easier with Fakes/Stubs/Spies than mocks. Because in the former, the contract specification is in one location. While in mocks, it’s every test which uses that contract.
Re Top-Down vs Bottom-up design:
A Top-Down approach would lead you to a better domain designed application, because you’re only doing what is needed, and your whole process of creating all objects necessary are focused to just that. However, the Bottom-Up approach is useful as well when tackling technical limitations.
If you do a Bottom-Up approach, and once your reach the top and find it that the contracts of the lower layers can not be easily used by your top-layer, then either you hack it out in the middle so that they can communicate, or you change the contract of the lower layer and do necessary changes downwards, then continue from where you left of.
And if you’re doing a Top-Down approach, and you reach a technical limitation at the bottom layer, you may have to change the contract of the bottom layer to something feasible and propagate the changes upwards, then continue from where you left of.
If your risk is usually on the domain design (which usually is), then go for the Top-Down. But if you foresee a probable technical limitation, go for the Bottom-Up. And if you’d like, you can mix and match and meet in the middle.
It will be interesting to see what mocking framework Steve used. I am guessing JMock or EasyMock. When you use something like mockito and seperate your stubs and mocks, the tests might turn out less fragile.
I do agree with the author that Top down TDD aided by a mock frame work gives you more velocity than a bottom up approach using purely state based interaction.
Top down helps you see the forest from the trees.
I’m not sure if I’m reading this line correctly or not:
““Doing top-down makes it much more likely that I’ll hit my destination”, said Marick, pointing out that there is no rational reason to choose top-down over bottom-up design, but from his experience the style of working with mocks leads to better design faster.”
Does that mean there’s no rational reason to choose Top Down over Bottom Up or no rational reason to choose Top Down period?