Mocks and expectations

JBehave’s Story Runner runs through scenarios as follows:

Given a context
When an event happens
Then this outcome occurs.

So you’d think it would visit these in the order “context, event, outcome”.

Unfortunately, the mocks all have to be set up before the event – so what you actually get is “context, outcome (setUp), event, outcome (verify)”.

What’s more, when you come to replace the mocks with real code, expectations in setUp become checks in verify,
eg: mockHellboundGui.expects("setVisible") before the event becomes assertTrue(swingHellboundGui.isVisible()) after the event.

The expectations are a kind of verification anyway. Wouldn’t it be great if you could set them up in verify, instead of setUp? If you could just create mocks in setUp (or even in the event, perhaps, where you use them), then add all the expectations at the end, after the methods have been called but before you call mockFoo.verify()? You wouldn’t do expects("setVisible"), you’d do expected("setVisible") instead.

This would also help with another problem I have; where the (real) Hellbound game factory creates a game, but I can’t expect the game to be passed to the arguments of any of my mocks as I didn’t have hold of it in setUp.

Unfortunately all the current mock schemes insist on you expecting a method before it gets called, or they fall over. What a pain.

This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to Mocks and expectations

  1. anonymous says:

    Elizabeth,

    I may have missed the point of your post since I am not familiar with JBehave, but as far as mocks go your complaint struck me as unusual.

    The point of mocks is to stand in for an object that you recognize a dependency on but don’t want to couple your test to. Therefore you set up expectations to ensure your object under test interacts with the dependency as expected. The expectations are statements about how the interaction should be orchestrated and the verify is the verification that things worked out as expected. It sounds to me that if things worked as you stated above you would be testing the mocks instead of the object under test.

    So in your eg: mockHellboundGui.expects(“setVisible”) is really saying that the setVisible method will be called and you will verify (later on) that it was called. Without the expectation your code will fail. You just don’t care what it really does for your test.

    Jeff Santini, fellow Thoughtworker

  2. sirenian says:

    Hi Jeff,

    I’m using JBehave’s story running, in which mocks gradually get replaced with the real code, thus providing functional tests (as opposed to unit tests).

    And yes; Manish made this point to me too, so I’ve had a rethink since. I would still like the ability to check that a method got called with particular arguments, after the fact (sometimes there really is no way to do this beforehand).

  3. anonymous says:

    Why is there no way to do this beforehand? If you don’t know what should happen, how can you even write a test?

  4. sirenian says:

    You know that the game factory will produce a game, and that the shape factory will produce a shape, but you don’t know what that shape will be…

  5. sirenian says:

    My main objection was having to move the expectation in the setup to verification in the “verify” method. As Manish kindly pointed out, the story runner is concerned with design, not testing – the behaviour classes do that – so I don’t need to worry about testing the behaviour once the design uses real classes instead of mocks. All it does is check that it runs, and help you design better code top-down.

  6. anonymous says:

    It sounds as if you are mixing the code that coordinates your objects (game and shapes, for example) and the code that instantiates objects. Pull the instantiation out of the coordinator object and into a factory. Now you can mock the factory and test the coordination code. The factory will probably be simple enough that you can test it in functional tests without needing unit tests; it might be necessary to unit test the factory if it does any logic itself but you won’t need mocks for that.

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 )

Google+ photo

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

Connecting to %s