Object Mentor Blog: Manual Mocking: Resisting the Invasion of Dots and Parentheses

Manual Mocking: Resisting the Invasion of Dots and Parentheses

Uncle Bob — Wed, 28 Oct 2009 18:12:16 -0500

The twittersphere has been all abuzz today because of something I tweeted early this morning (follow @unclebobmartin). In my tweet I said that I hand-roll most of my own mock objects in Java, rather than using a mocking framework like mockito.

The replies were numerous and vociferous. Dave Astels poignantly stated that hand-rolling mocks is so 2001!

So why do I roll my own mocks?

Consider the following two tests:

public class SelectorTest {
  private List<Object> list;

  @Before
  public void setup() {
    list = new ArrayList<Object>();
    list.add(new Object());
  }

  @Test
  public void falseMatcherShouldSelectNoElements_mockist() {
    Matcher<Object> falseMatcher = mock(Matcher.class);
    Selector<Object> selector = new Selector<Object>(falseMatcher);
    when(falseMatcher.match(anyObject())).thenReturn(false);
    List<Object> selection = selector.select(list);
    assertThat(selection.size(), equalTo(0));
  }

  @Test
  public void falseMatcherShouldSelectNoElements_classic() {
    Matcher<Object> falseMatcher = new FalseMatcher();
    Selector<Object> selector = new Selector<Object>(falseMatcher);
    List<Object> selection = selector.select(list);
    assertThat(selection.size(), equalTo(0));}

  private static class FalseMatcher implements Matcher<Object> {
    public boolean match(Object element) {
      return false;
    }
  }
}

The first test shows the really cool power of mockito (which is my current favorite in the menagerie of java mocking frameworks). Just in case you can’t parse the syntax, let me describe it for you:

falseMatcher is assigned the return value of the “mock” function. This is a very cool function that takes the argument class and builds a new stubbed object that derives from it. In mockito, the argument can be a class or an interface. Cool!

Now don’t get all panicy about the strange parenthetic syntax of the ‘when’ statement. The ‘when’ statement simply tells the mock what to do when a method is called on it. In this case it instructs the falseMatcher to return false when the ‘match’ function is called with any object at all.

The second test needs no explanation.

...

And that’s kind of the point. Why would I include a bizzare, dot-ridden, parentheses-laden syntax into my tests, when I can just as easily hand-roll the stub in pure and simple java? How hard was it to hand-roll that stub? Frankly, it took a lot less time and effort to hand-roll it than it took to write the (when(myobj.mymethod(anyx())).)()).))); statement.

OK, I’m poking a little fun here. But it’s true. My IDE (InteliJ) generated the stub for me. I simply started with:

Matcher<Object> falseMatcher = new Matcher<Object>() {};

InteliJ complained that some methods weren’t implemented and offered to implement them for me. I told it to go ahead. It wrote the ‘match’ method exactly as you see it. Then I chose “Convert Anonymous to Inner…” from the refactoring menu and named the new class FalseMatcher. Voila! No muss, no fuss, no parenthetic maze of dots.

Now look, I’m not saying you shouldn’t use mockito, or any of these other mocking tools. I use them myself when I must. Here, for example, is a test I wrote in FitNesse. I was forced to use a mocking framework because I did not have the source code of the classes I was mocking.

  @Before
  public void setUp() {
    manager = mock(GSSManager.class);
    properties = new Properties();
  }

  @Test
  public void credentialsShouldBeNonNullIfServiceNamePresent() throws Exception {
    properties.setProperty("NegotiateAuthenticator.serviceName", "service");
    properties.setProperty("NegotiateAuthenticator.serviceNameType", "1.1");
    properties.setProperty("NegotiateAuthenticator.mechanism", "1.2");
    GSSName gssName = mock(GSSName.class);
    GSSCredential gssCredential = mock(GSSCredential.class);
    when(manager.createName(anyString(), (Oid) anyObject(), (Oid) anyObject())).thenReturn(gssName);
    when(manager.createCredential((GSSName) anyObject(), anyInt(), (Oid) anyObject(), anyInt())).thenReturn(gssCredential);
    NegotiateAuthenticator authenticator = new NegotiateAuthenticator(manager, properties);
    Oid serviceNameType = authenticator.getServiceNameType();
    Oid mechanism = authenticator.getMechanism();
    verify(manager).createName("service", serviceNameType, mechanism);
    assertEquals("1.1", serviceNameType.toString());
    assertEquals("1.2", mechanism.toString());
    verify(manager).createCredential(gssName, GSSCredential.INDEFINITE_LIFETIME, mechanism, GSSCredential.ACCEPT_ONLY);
    assertEquals(gssCredential, authenticator.getServerCredentials());
  }

If I’d had the source code of the GSS classes, I could have created some very simple stubs and spies that would have allowed me to make these tests a lot cleaner than they currently appear. Indeed, I might have been able to test the true behavior of the classes rather than simply testing that I was calling them appropriately…

Mockism

That last bit is pretty important. Some time ago Martin Fowler wrote a blog about the Mockist and Classical style of TDD. In short, Mockists don’t test the behavior of the system so much as they test that their classes “dance” well with other classes. That is, they mock/stub out all the other classes that the class under test uses, and then make sure that all the right functions are called in all the right orders with all the right arguments. etc. There is value to doing this in many cases. However you can get pretty badly carried away with the approach.

The classical approach is to test for desired behavior, and trust that if the test passes, then the class being tested must be dancing well with its partners.

Personally, I don’t belong to either camp. I sometimes test the choreography, and I sometimes test the behavior. I test the choreography when I am trying to isolate one part of the system from another. I test for the behavior when such isolation is not important to me.

The point of all this is that I have observed that a heavy dependence on mocking frameworks tends to tempt you towards testing the dance when you should be testing behavior. Tools can drive the way we think. So remember, you dominate the tool; don’t let the tool dominate you!

But aren’t hand-rolled mocks fragile?

Yes, they can be. If you are mocking a class or interface that it very volatile (i.e. you are adding new methods, or modifying method signatures a lot) then you’ll have to go back and maintain all your hand-rolled mocks every time you make such a change. On the other hand, if you use a mocking framework, the framework will take care of that for you unless one of the methods you are specifically testing is modified.

But here’s the thing. Interfaces should not usually be volatile. They should not continue to grow and grow, and the methods should not change much. OK, I realize that’s wishful thinking. But, yes, I wish for the kind of a design in which interfaces are the least volatile source files that you have. That’s kind of the point of interfaces after all… You create interfaces so that you can separate volatile implementations from non-volatile clients. (Or at least that’s one reason.)

So if you are tempted to use a mocking framework because you don’t want to maintain your volatile interfaces, perhaps you should be asking yourself the more pertinent question about why your interfaces are so volatile.

Still, if you’ve got volatile interfaces, and there’s just no way around it, then a mocking framework may be the right choice for you.

So here’s the bottom line.

It’s easy to roll your own stubs and mocks. Your IDE will help you and they’ll be easier and more natural to read than the dots and parentheses that the mocking frameworks impose upon you.

Mocking frameworks drive you towards testing choreography rather than behavior. This can be useful, but it’s not always appropriate. And besides, even when you are testing choreography, the hand-rolled stubs and mocks are probably easier to write and read.

There are special cases where mocking tools are invaluable, specifically when you have to test choreography with objects that you have no source for or when your design has left you with a plethora of volatile interfaces.

Am I telling you to avoid using mocking frameworks? No, not at all. I’m just telling you that you should drive tools, tools should not drive you.

If you have a situation where a mocking tool is the right choice, by all means use it. But don’t use it because you think it’s “agile”, or because you think it’s “right” or because you somehow think you are supposed to. And remember, hand-rolling often results in simpler tests without the litter of dots and parentheses!

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by ?????? ????

Sat, 24 Jul 2010 14:47:16 -0500

thanks about it

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Buzzword

Tue, 13 Jul 2010 02:56:23 -0500

Summer is very hot, who can wear article 7 minutes of pants, must the cowboy oh, the best side or a small beads embroidery that paillette, or color, the best is shallow blue, body parts, the condole belt unlined upper garments grows out of a piece of short sweater, small hollow-out sweater is better, there is colour with cream-colored, white, give priority to, in a few pieces of bright, very pretty, tie-in use: oh!!!!!!!!!!!

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Hoop skirt

Tue, 13 Jul 2010 02:55:05 -0500

clothing

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Kevin Durant jerseys

Mon, 28 Jun 2010 02:27:39 -0500

I may not shift camps sometime soon but I will give your suggestions a try.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by yosisi

Mon, 14 Jun 2010 09:03:27 -0500

http://www.kefpo.co.il thanks about it

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Daniel

Wed, 19 May 2010 12:15:09 -0500

I belong to the classical camp and am happy that someone who professes to not belong to either camp has presented a very comprehensive look at mockism. I may not shift camps sometime soon but I will give your suggestions a try.

Fruitarian Diet

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Nex

Tue, 20 Apr 2010 11:17:35 -0500

I prefer to work on game programming.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by ShAaNiG

Mon, 12 Apr 2010 05:57:27 -0500

I think that too often we get carried away by shiny things, and forget that there may be less sexy, but more practical ways of achieving tasks.

Wholesalers

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by ShAaNiG

Sat, 10 Apr 2010 11:09:49 -0500

On the other hand, spies are superior to mocks in every conceivable way as far as I can tell. That might give you additional incentive to hand code, since mock frameworks often aren’t capable of generating spies.

Wholesale Brand Name Clothing

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by ShAaNiG

Fri, 02 Apr 2010 05:41:10 -0500

great info mate. will read it. thanks in advance

Prudential West

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by moncler clearance

Wed, 31 Mar 2010 22:14:33 -0500

Very quietly I take my leave.To seek a dream in http://www.edhardy-buy.com/ starlight.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by highkoo ugg boots

Wed, 31 Mar 2010 22:13:15 -0500

all products are high quality but low price,welcome to http://www.uggjordanghd.com/.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Kooba Handbags

Wed, 31 Mar 2010 22:11:30 -0500

Living without an aim is like sailing without a compass. with a new http://www.handbags4buy.com/ idea is a crank until the idea succeeds.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by UGG Classic Metallicaz`

Wed, 31 Mar 2010 22:08:29 -0500

welcome to http://www.uggboots4buy.com/ l,will have a unexpection.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Ga,es365

Sun, 07 Mar 2010 06:15:16 -0600

I prefer to work on game programming.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by John Erickson, Cousins Subs,

Tue, 29 Dec 2009 20:40:12 -0600

SHUT YOUR GOD DAMN MOTHER FUCKING PUNK ASS MOUTH JACK YOU FAG FUCK YOU DON’T KNOW WHAT THE FUCK YOU ARE YAPPING ABOUT.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Jack

Tue, 29 Dec 2009 20:35:15 -0600

FUCK YOU!

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by dungeon fighter gold

Fri, 25 Dec 2009 02:15:02 -0600

thank you for sharing.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by sikis

Wed, 23 Dec 2009 16:01:44 -0600

bu kodlar ne i?e yar?yor bi anlam veremedim?

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Chris Morris

Mon, 02 Nov 2009 11:05:56 -0600

Vindication? http://clabs.org/blogki/index.cgi?page=/ComputersAndTechnology/DiyMocks

JB didn’t agree with me either …

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Questia App

Mon, 02 Nov 2009 00:29:19 -0600

It is only the text, Which i can understood, however, programming code has just gone above my brain. Indeed, this would be a great idea to be used in Twitter.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Philip Schwarz

Sun, 01 Nov 2009 08:03:31 -0600

@Uncle Bob

In The Art of Unit Testing, Roy Osherove says:

In a test where you test only one thing (which is how I recommend you write tests), there should be no more than one mock object. All other fake objects will act as stubs. Having more than one mock per test usually means you are testing more than one thing, and this can lead to complicated or brittle tests.

Your test credentialsShouldBeNonNullIfServiceNamePresent conforms to this practice: it has one mock called manager, and two stubs called gssName and gssCredential.

Do you think it would enhance readability to have mock names contain ‘mock’, and stub names containing ‘stub’, like in the Apps flavour of Hungarian Notation?

e.g. 1: mockManager, nameStub and credentialStub
e.g. 2: mockManager, stubbedName and stubbedCredential.

We would then have:

when(mockManager.createName(anyString(), (Oid) anyObject(), (Oid) anyObject())).thenReturn(stubbedGssName);
...
when(mockManager.createCredential((GSSName) anyObject(), anyInt(), (Oid) anyObject(), anyInt())).thenReturn(stubbedGssCredential);
...
NegotiateAuthenticator authenticator = new NegotiateAuthenticator(mockManager, properties);
...
verify(mockManager).createName("service", serviceNameType, mechanism);
...
verify(mockManager).createCredential(stubbedGssName, GSSCredential.INDEFINITE_LIFETIME, mechanism, GSSCredential.ACCEPT_ONLY);
...
assertEquals(stubbedGssCredential, authenticator.getServerCredentials());

This could also help to quickly check that there is no verification of methods called on stubs.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Erik Przekop

Sat, 31 Oct 2009 20:10:48 -0500

I think the comments point out clearly that this is a “religious” argument to some extent.

I use EasyMock very often, and I think I need to write more hand-rolled mocks / stubs. At the very least I need to try it and see how well it works for a given situation.

I certainly don’t agree with the assertion that boils down to “good programmers should be able to read code using mocks” (which is what I took away from Reflective Surface’s post). That’s as bad as saying “it was hard to write, so it should be hard to read.”

If a mediocre programmer can’t make sense of your code, then it could (and usually should) be written more clearly.

I really need to give Mockito a try, though. I’m not very keen on doing behavior-based verification unless I absolutely have to. My (admittedly stone-aged) mind finds it much easier to understand tests that verify state.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Philip Schwarz

Sat, 31 Oct 2009 19:34:01 -0500

@Franco Lombardo

Which assertion better communicates that ‘it is true that the selection size is zero’ ?

If we use

assertEquals(0, selection.size());

it reads as ‘it is true equals zero selection size’. Not too clear. Partly because ‘equals’ is used as a prefix operator, as in the LISP-like (= a b), and partly because the result operand comes before the computation operand, as in the LISP-like (= result computation).

If we use

assertThat(selection.size(), equalTo(0));

it reads as ‘it is true that selection size equal to zero’. That is clearer. The equals is now in infix position, as in a = b, and the computation comes before the expected result: computation = result. But we can do better.

If we use

assertThat(selection.size(), is(equalTo(0)));

it reads as ‘it is true that selection size is equal to zero’, which is pretty much what we are trying to communicate.

Which one do you prefer?

As it says in this Hamcrest tutorial, the ‘is()’ matcher is pure syntactic sugar, to make your tests as readable as possible.

"Manual Mocking: Resisting the Invasion of Dots and Parentheses" by Philip Schwarz

Sat, 31 Oct 2009 18:05:19 -0500

In The Art of Unit Testing, which according to Michael Feathers (who wrote the Foreword) is ‘an important title that should have been written years ago’, Roy Osherove, the author, says:

Although there are many advantages to using isolation frameworks [a set of programmable APIs that make creating mock and stub objects much easier], there are some possible dangers too. Some examples are overusing an isolation framework when a manual mock object would suffice, making tests unreadable because of overusing mocks in a test, or not separating tests well enough.

He also says:

Learn how to use the advanced features of an isolation framework… and you can pretty much make sure that anything happens or doesn’t happen in your tests. All you need is for your code to be testable.

You can also shoot yourself in the foot by creating overspecified tests that aren’t readable or will likely break. The art lies in knowing when to use dynamic versus handwritten mocks. My guideline is that, when the code using the isolation framework starts to look ugly, it’s a sign that you may want to simplify things. Use a handwritten mock, or change your test to test a different result that proves your point but is easier to test.