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.
It seems like you’d end up writing two lines of code, one stub and one verify in cases where you want to verify that something was called that also returns something that is important to the execution flow. On your google code you provide this example:
EasyMock
Control control = createStrictControl();
List one = control.createMock(List.class);
List two = control.createMock(List.class);
expect(one.add(“one”)).andReturn(true);
expect(two.add(“two”)).andReturn(true);
control.replay();
someCodeThatInteractsWithMocks();
control.verify();
Mockito
List one = mock(List.class);
List two = mock(List.class);
someCodeThatInteractsWithMocks();
InOrder inOrder = inOrder(one, two);
inOrder.verify(one).add(“one”);
inOrder.verify(two).add(“two”);
What if returning true from those two methods is important?
>It seems like you’d end up writing two lines of code, one stub and one verify
Not really: stubs are implicitly verified – by the fact that stubbed value is essential for processing. Returned value is just more interesting… Do you remember the old days when we craft our stubs by hand? Did you ever verify your hand-written stubs?
> What if returning true from those two methods is important?
Then I’d stub it ;) In most cases an interaction is either asking (which I want to stub) or telling (which I want to verify).
I’m not quite getting it.
Based on the example above, aren’t your mocks in fact stubs? They’re not verifying anything. So probably the library name is a little bit deprecated?
I personally like stubbing instead of mocking but I would like to have a library that can do both (rSpec does that).
>aren’t your mocks in fact stubs?
They are spies. You can ask them questions about interactions. Effectively you can verify them.
>the library name
Only geeks see any relation to mocking. It’s all about drinking! :)
[...] intuitive approach: you ask questions about interactions after execution. Using mockito, you can verify what you want. Using expect-run-verify libraries you are often forced to look after irrelevant [...]