Mockito @ Agile 2008

Just submitted session proposal for Agile 2008. It’s about Mockito (yes, I know I’m boring).

Competition is fierce and without proper (read: famous) name it will be difficult to get approved. But anyway: deadline for submissions is tomorrow. If you have any feedback about my session and you are willing to share it with me before end of tomorrow – I would be grateful.

I’m gonna present short version of this session during coming Last Thursday at Holborn office – see you there!

Can I test what I want, please?

Here’s the deal:

In state based testing (or return value testing) I assert that certain property has changed. I don’t care if other properties have changed – unless I explicitly write assertions for them. Great benefit of this style is the flexibility of testing: I can write small, targeted test methods. Basically, I can test what I want.

In interaction based testing I expect an interaction to happen. Even if I don’t care about other interactions I still have to expect them – to satisfy invasive mocks. This is how most mocking frameworks work and as a result, I cannot write small, targeted test methods. Basically, I cannot test what I want.

Some mocking frameworks are not invasive. Others offer tricks to reduce this problem – with various success rate and usually with side effects. Instead of jumping into examples let me ask you:

Does your mocking framework let you test what you want?

Expecting a single interaction in most mocking frameworks means: 1. this interaction must happen. 2. other interactions must NOT happen. Do you imagine if an innocent assertion of the state worked like that? Asserting one property meaning also asserting that NONE of the other properties have changed?

Let me rephrase my initial question: Why testing interactions has to be more defensive than testing state?

Is it because we fell in love with pre-programmed, intelligent mocks? Is it because of the way mocking frameworks are implemented? Or perhaps because of the strive to have a decent point of failure – mock can bark with unexpected interaction straight in the code so it’s very easy to find it?

I’m not buying it. When it comes to behaviour verification, Mockito provides excellent point of failure. Also, Mockito can detect any kind of unexpected interactions. Oh, and Mockito lets me test what I want…

Mockito mocks are tamed. They don’t make decisions for me. They don’t know which interactions are expected or unexpected. I rule my mocks. I rule my code. And it pays back generously: code is cleaner and reacts better to changes.

By now, you’ve probably figured out that Mockito is not strictly a mocking framework. It’s rather a spying/stubbing framework but that’s a story for a different post.

expect-run-verify… Goodbye!

Expect-run-verify is the most common pattern in mock frameworks. (update: I called it record-replay-verify before – my bad – expect-run-verify is what I really meant).

What’s wrong with it?

1. Codebase suffers. Test methods become noisy. I have to expect/record some interactions not because I want to test them but because mocks complain if I don’t do it.
2. Doesn’t give me a natural test-drive. I prefer when expectations become assertions and appear after execution – it’s very intuitive.
3. Tests are fragile. Test driving new functionality that requires additional interaction often breaks all tests. Thanks to the aggressive nature of expect-run-verify.
4. Could give better failures. When expectation becomes assertion, failure shows exact line of code. No more deciphering exception messages – just click on first element on stack trace.
5. Could read better. Separation of stubbing and expectations reads really nicely.

Today I discovered MoQ – little mocking library for .NET. When I read how MoQ was invented I see many similarities with my own thinking process that pushed me to write Mockito.

MoQ uses C# 3.0 sugar like lambda expressions. Mockito is a java creature. Both don’t like record/playback model. Mockito goes even further and abandons expect-run-verify.

Expect-run-verify…

Goodbye!

Let me enjoy most natural test-drive: as close to state based testing as possible. Expectations in Mockito are like assertions – good old friends of state based testing.

Java TDDer have several options these days:

1. Using hand crafted stubs/mocks: too much boilerplate, too many lines of code, chaos of stubs.
2. Using existing mock libraries: less some obscure exceptions it’s all expect-run-verify stuff.
3. Mockito: just try it and tell me what you don’t like about it :)

I know that many test-infected java people on this planet don’t use mock frameworks. They code mocks/stubs from scratch because they find mock libraries too annoying. Mockito offers simplicity and flexibility of hand crafted mocks and yet eliminates so much boilerplate code. I encourage you to try it out.