I’m not suggesting we shouldn’t have stubs, which is what you’re describing, and Mockito has good support for that. My point is that we can do the actual expectations after the fact, in a black box flight recorder kind of way, which I think leads to more readable tests. And the {{ syntax gymnastics }} with JMock 2 just hurts my brain!

I feel like some sort of lamer for commenting on a post from pre-history, but it really spoke to an insight I’d had recently re mocks and BDD. That insight too is probably ancient history to you, but since I’ve only just discovered BDD (yes, I know) I’ll take that risk! Love the blog, InfoQ presentations, etc etc, btw.

I agree that endotesting and top-down development (which is really what BDD and TDD should be called, imho) don’t sit well together. But I think frameworks like JMock still have a place:

- you mock to implement givens without having to… implement them

- givens are declarative

- so if I want to express ‘given there is a flight number BA016′, I’d do that in JMock by saying ‘allowing(flightService).getFlight(‘BA016′); will return new Flight(‘BA016′)’; … in other words, I’m not _requiring_ the call to be made, merely saying what should result if it is

- presumably, since I’ve been doing the development top-down, FlightService is the only way to get a flight – or at least it’s mutually consistent with all other ways of creating and retrieving them – so this is a valid approach. And I suspect that as you continue the BDD process, you make sure givens are refactored to be shared, which again reinforces the mutual consistency requirement on the implementation

- even if the codebase hasn’t been developed top-down, and FlightService isn’t the only way to get a flight, but the test passes notwithstanding the fact that the allowed call isn’t made – perhaps because the implementation under test uses a new magically injected TelepathyService – then from the point of view of developing the behaviour I’m interested in here, I don’t really care. I realise I might want to be told that the mechanism I’d expected to be used wasn’t, for other reasons, but for the behaviour here it’s not the prime concern.

And re patterns like new Expectations() {{}} – I’ve found myself moving towards building expectations instead using an Expectations instance field in my test classes. Especially with a few static imports of Expectations methods, it’s just as expressive and makes for easier refactorings of ‘givens’.

In all cases of using a unit test framework, no matter the intent of the test methods, one thing is certainly…

How are you distinguishing “get mocking” form “gain fluency with the tool”?

I agree with using JMock as a teaching tool – I’ve had lots of success with it over the years. And I can’t understate the impact it’s had in terms of the wider adoption of mocking, as well as the secondary effects of its matcher library (assertThat and hamcrest).

I’m interested in how adopting Mockito would “address some weak design and coding habits”. Is it about working around them so you can get work done in spite of the bad habits, or does it provide a more gradual and intuitive path away from them (than expectation-based mocking)?

An experienced TDDer will usually be equally fluent/expressive/focused using any decent mocking library, but I’ve been finding that novices and advanced beginners “get” mocking more quickly with Mockito than with the expectation-based alternatives. My sample group has been small so it may just be these people in this context. I haven’t been using it for long enough – or across enough different contexts – to have decent empirical evidence yet.

But, it also became clear that he wrote Mockito to address some weak design and coding habits in his project and that the existing mocking frameworks were doing exactly their job of forcing them into the open. How a team should respond to that feedback is an interesting question.

In the meantime, I’ve found that I /can/ teach using the existing frameworks if I concentrate on what they were intended for: focusing on the relationships between collaborating objects. I’ve seen quite a few students light up when they get the point. In fact, the syntactic noise in jMock really helps to bring this out, whereas it’s easy for it to get lost with easymock and mockito.

I’ve been using JMock 1 and 2 for a while in the way you describe – writing the example/test ahead of implementing the code. I still do the same thing with Mockito but I find the flow works better. I’ve also found that coaching TDD using Mockito seems to work better than with JMock or EasyMock.

The only difference between state-based and interaction-based testing is now whether I verify(...) or assertThat(...) things are as I expect them to be. It’s still very much test-driven – the test is written before I implement any code – but the people I’m coaching seem more comfortable with Mockito’s verify afterwards model, and I’m finding it fits the cycle of TDD more naturally.

Putting the expectations after the ‘when’ feels very different from putting them before. Maybe I’m reading too much into this but the expectations-at-the-top model seems to be saying “think about the expected interactions before thinking about the ‘when’” and the expectations-at-the-bottom model seems to say “put in the ‘when’ and then fill in the expectations”

That turn your brain inside-out feeling isn’t always a bad one and too often “more intuitive” is a technical term meaning “relieves me of the need to think” rather than “makes doing the right think easier.” I wonder exactly which it is in this case.