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.
Liz Keogh, lunivore 
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
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).
Why is there no way to do this beforehand? If you don’t know what should happen, how can you even write a test?
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…
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.
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.