DanNorth.net

…or why Mockito is my new friend.

So what’s endotesting?

The pioneers of the technique we now know as mocking presented a paper at the XP 2000 conference, where they first introduced the idea to a wider audience. They prefaced it with the quote:

bq. “Once,” said the Mock Turtle at last, with a deep sigh, “I was a real Turtle.”

The Lewis Carroll reference appeals to me because I often cite Humpty Dumpty as the real creator of behaviour-driven development:

bq. “When I use a word, ” said Humpty Dumpty in a rather scornful tone, “it means just what I choose it to mean, neither more nor less.”

These folks – Tim Mackinnon, Steve Freeman and Philip Craig – realised that you could drop in a fake instance of an object that you could get to “fail fast” if it received a method call it wasn’t expecting:

bq. We propose a technique called Mock Objects in which we replace domain code with dummy
implementations that emulate real code. These Mock Objects are passed to the target domain
code which they test from inside, hence the term Endo-Testing.

This approach – endotesting – led to the creation of a number of open source frameworks, most notably JMock (written by Tim and Steve among others) and EasyMock. The basic premise of these frameworks was to make it easy to create a mock object and prime it with a number of expectations. (Your makeCheese method will be called with the parameter @”brie”@. When this happens, return the value BRIE.)

Having set up a mock object with its expectations, you wire it up into a bunch of objects and then poke the outermost object. If all goes well you can interrogate your mock and it will tell you its makeCheese method was called. If it doesn’t go well – well that’s when the magic happens. If you call an unexpected method on a mock it will fail during the test, giving you a stack trace from exactly where the unexpected method call happens. You don’t have to start rummaging through the call sequence trying to work out where it all went wrong, and your test doesn’t carry on running after the unexpected method call to produce a bogus result that doesn’t make any sense.

How we use mocks

Now if you are wiring together a complex group of objects to do something, endotesting-style mock objects are invaluable. I had a situation a while ago where we had a suspect XML message being sent over the wire to an external system. We wrote an integration test where we injected a mock for the external system into a complex object structure – the mock was primed to only accept a valid XML message – and when it failed the stack trace gave us a direct line into the failure. It turned out one of the eight objects wired together was doing an incorrect transformation on part of the XML which meant the outbound message was invalid. By using a mock object in this way we were able to identify exactly where the error was occurring.

However nowadays mocks are mostly used for describing interactions between objects in the context of test-driven development. Your object under test interacts with one or two other objects that you represent by interfaces (roles) that you probably inject into its constructor as mocks. Your test is verifying that the object calls the appropriate methods on its collaborators. In this simplistic scenario, the reason for a failure is usually pretty obvious – you haven’t written the code yet or you are passing the wrong parameters into the method call.

Say you are developing a simple calculation where you expect the answer to be 7 but the code is producing the answer 10, then it isn’t that difficult to work out where the problem is. You don’t need the code to fail as soon as the value of 10 is produced. The fact that the answer is 10 and you expected 7 is enough to triangulate the error. This is classic post hoc state-based testing. Similarly, if you expect your object to call makeCheese on the CheeseFactory and it doesn’t, well you are likely to have a pretty good idea where it doesn’t. So all you really need your mocking library to do is act like a flight recorder black box. You can ask it after the fact: hey CheeseFactory, did my object call your makeCheese method? If it didn’t you probably know why. (And if you don’t it may be an indication that your test is too complicated.)

A more intuitive approach to mocking

This then means that you can treat assertions on method calls just like you treat assertions on state changes, asking the various collaborators what happened after the fact rather than priming your mock objects ahead of time, which in turn means you don’t need to turn your brain inside-out creating a flow like this:

  // Given
  // ... create mocks
  // ... wire up my object

  // Expect (eh?)
  funky.dslWith("stringsForMethods")

  // When
  myObject.makeBrie();

  // Then
  verifyExpectationsSetTwoParagraphsEarlier(); // you remember right?

where it is much more intuitive to write something like:

  // Given
  // ... create mocks
  // ... wire up my object

  // When
  myObject.makeBrie();

  // Then
  verify(CheeseFactory).makeCheese("brie"); // how nice is that?

This, then, is the premise of Mockito. It uses a similar syntax to EasyMock – which means my generics-aware IDE is able to do proper completions and refactorings – but it doesn’t have any of that record/playback nonsense. Nor does it require me to do any of the clever @{{ anonymous constructor }}@ gymnastics that JMock 2 introduced. It just sets up mocks on interfaces (although it allows me to mock concrete classes which I think is a retrograde step – remember kids, mock roles, not objects) and gives me a black box recorder that I can interrogate after the fact.

When I asked Mockito’s author, Szczepan Faber, how he came up with the insight that mocking in the context of TDD was a completely separate problem from endotesting, he replied: what’s endotesting?

It turned out that in order to create a mocking framework to support TDD it helped to have no idea where the encumbent frameworks – JMock and EasyMock – had come from. In the same way that a unit testing framework got co-opted as the enabler for TDD in Java, an endotesting framework became the enabler for method assertions in interaction-based testing. But if you start from the ground up – with a nod to EasyMock and with a pragmatic dose of Java 5 generics – you can get a simple, elegant and intuitive framework for verifying interactions between collaborators. There’s still a place for traditional endotesting in the context of gnarly integration tests, but I’m liking Mockito. I think you will too.

I was in a hotel in Stockholm recently and I noticed a bottle opener attached to the wall in the bathroom. There was a bilingual sign under it which got me thinking about the term “bottle opener” itself. (I was giving a talk about BDD the next day so I was already thinking about how language is used.)

It occurred to me that “bottle opener” is a great example of goal-oriented vocabulary. The device itself is actually a cap remover, and it only works on one particular design of metal cap. The reason I use it, however, is to enable me to get to the beer in the bottle. Hence “bottle opener” rather than “cap remover”.

The task is just detail

There is more to this than just linguistic curiosity. If you use task-oriented vocabulary it can cause you to focus on the means rather than the goal, which in turn can limit your options. My favourite example of this is the term “search engine”. Searching is the activity I have to do because I’ve misplaced my keys and I’m locked outside. What I want is a find engine!

Google realises this. When I type something into Google, it guesses what I’m likely to be trying to find, not what I happen to be typing into the box. If I type in “Stockholm map”, I’m likely to be looking for a map of Stockholm (first three results are actual maps – presented as pictures) or some information about the town itself. If I type “hotels Stockholm” I’m probably planning a trip there and voila! lots of useful results for the traveller. Other “search” engines do just that – they search, and produce lists of results. It’s then down to me to sift out the ones I care about to get me closer to my goal.

“Blur” on a problem

We talk about “focusing on a problem” in order to solve it. This is a task-oriented phrase. An alternative would be to stand far enough back that you see the problem in its proper perspective. If anything you are “blurring” on the problem – deliberately losing focus on the detail to see if any larger-scale structure emerges.

I often describe BDD as outside-in development. You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done. With a legacy application it can be difficult to remain outside enough, or to get a good enough frame of reference for “done”. Blurring can help with this.

For the last six months I’ve been involved in restructuring and re-architecting a legacy code base. It’s been quite a major undertaking, and has involved a number of false starts and dead ends. (I’m planning to write it up as an experience report at some point, but given my current throughput of things I plan to write, don’t expect it any time soon.) During this project, I’ve often found myself struggling to choose between alternative strategies, or unsure of where to go next. In these situations I’ve found that stepping back and “blurring” gives me enough perspective for one of the alternatives to become “obvious”. In fact a couple of my teammates have picked up on this and will actually suggest it as an activity when we are pairing. “We’re thrashing here – let’s step back and start from the outside again.”

It could be as simple as asking “whose responsibility is this feature?” or “who is the actual client of this method call?”. You don’t need to know the answers – just verbalising the questions can give you enough “blur” to gain a better perspective.

Blur on time as well as space

Linus Torvalds recently gave a talk where he said the problem with source control isn’t branching, it’s merging. Again, by taking a broader perspective – in this case temporal rather than spatial – his insight is that the goal is a successful merge some time in the future, not the task of branching now.

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

_Props to James Lewis for helping me formulate these ideas. And for being really good at perspective._