We don’t design using mocks

I’ve found myself repeating this a few times lately, so maybe it will help some people out there.

In BDD, we don’t design using mocks.

We design by thinking about context, responsibility, collaboration and delegation, then we use mocks to express that (or stubs, in the case of context).

If we can find a different word to replace mock, stub, test-double, test-spy, etc., we probably should. In the spirit of BDD’s NLP roots, it might help us think differently. There may be more than one word for different uses. Any suggestions?

This entry was posted in bdd. Bookmark the permalink.

11 Responses to We don’t design using mocks

  1. Pat Maddox says:

    I thought “pixies” was the established nomenclature 🙂

  2. liz says:

    Pixicito… yes, that works.

  3. Thomas Eyde says:

    What’s wrong with ‘mocks’ all the time they are used to express the design? We are using the same mocking framework as we always do, unless we handwrite our mocks.

    The difference is in the method, or tactics. Not in the code we use. Mocks are overloaded as it is, I don’t think we need another one.

  4. “Understudy” They’re not the main actor, but they’re able to fill the role for now.

  5. One thing that’s been on my mind lately is that these names/patterns are all object focused, but the rubber really hits the road at the method level. We stub methods and set (mock) expectations for individual interactions on the same object – and sometimes that object is a real object (Test Specific Subclass in xUnit Test Patterns speak, mixin/metaprogramming in Ruby/Python/et al).

    So I’d like to see language evolve around things we do with methods rather than objects. We talk about Method Stubs and Message Expectations in The RSpec Book, and that might be a good start. But in light of your proposition here, maybe we need some new words.

    As for the idea that we don’t design using mocks, I _think_ that I understand what you mean because I read the next paragraph. But I fear for the skimmer who misses the context and walks away with “mocks are not a design tool.” To me, saying that we use mocks to express what we’ve discovered about context, responsibility, collaboration and delegation says “mocks are a design tool.” Which is subtly different from “we design with mocks.”

    Or maybe I’m just completely missing what you’re saying.

  6. Strangely I was just listening to Roy Osherove explaining the difference between “mock” and “stub” as types of “fake” (a distinction that feels more academic than real-world, if I’m honest).

    I sorta/kinda see the reasoning behind having a (random, cute) word with no connotation but my too-literal programmer brain recoils at the idea of having to explain the concept or (worse) agree a shared definition.

    I’d rather use a word or expression that describes the purpose for which the thing is to be used. Would “proxy” be too overloaded, if only for the developer? How about “substitute”? “Partial”? Leaving the box a little, what about “Cul-de-sac”, because input doesn’t really go anywhere?

    Or call it a “behaviour-exposure detecting assistant” or similar.

  7. Andy Palmer says:

    I was going to say pixies too.
    You didn’t say we had to create the library too 😛

    These are JMock pixies, these are Mockito pixies 🙂

  8. Dhaval Dalal says:

    How about collaborator? Though long, Its simple but conveys everything…again would work from NLP perspective as well.

  9. liz says:

    Apologies to those people whose comments only got moderated this morning. Not sure why WordPress wasn’t showing them to me (I was looking).

  10. Just found this after being offline while working on the book. [1]

    Our view is that it’s about “protocols”: which combinations of messages should be sent between collaborating objects. “Interfaces describe whether objects will fit together, Protocols describe whether objects will work together.”

    Nat and I both have some background in distributed systems (Nat has a lot) which informed our ideas when developing the idea of mocks–that, and pre- and post-conditions. That’s why the interactions are highlighted so strongly in jMock, partly out desperation with Java syntax, but also to make the protocol obvious.

    Personally, I’d prefer to see the original meaning reinstated rather than go through another round of renaming–but then we lost the previous rounds on that.

    [1] http://www.growing-object-oriented-software.com/

  11. Pingback: Preferring BDD over TDD | Software Artisan's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s