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?
- 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.
- Doesn’t give me a natural test-drive. I prefer when expectations become assertions and appear after execution – it’s very intuitive.
- Tests are fragile. Test driving new functionality that requires additional interaction often breaks all tests. Thanks to the aggressive nature of expect-run-verify.
- 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.
- 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:
- Using hand crafted stubs/mocks: too much boilerplate, too many lines of code, chaos of stubs.
- Using existing mock libraries: less some obscure exceptions it’s all expect-run-verify stuff.
- 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.
[...] Faber nous présente dans expect-run-verify… Goodbye! les raisons qui l’ont poussé à créer un nouveau framework de mocks – Mockito – en partant [...]
It sounds like you are thinking about objects in the wrong way and that’s why you are getting tied up in knots by expectations.
You should not be thinking about “expect/run/verify” or the internal data stored in your objects.
You should be thinking about the communication between your objects and describing those messaging patterns.
Mockito can’t do that. For example, how can you say that in one state a query method is stubbed to return value A, then a single call to a command method puts the object into a state in which the query method will return value B.
Abstract state machines one of the fundamental design techniques of OO programming, the stuff they teach in the first year programming courses at university. But Mockito can’t work with it. It’s only barely useful for OO programming.
Are you complaining about the fact that Mockito mocks are stateless? Well, that’s the point! Mocks are lightweight, test-drive is a pleasure, test code is clean & simple which hopefully pushes the app code to be simple. We’re always open to suggestions, though. Show us an example from your code where you use mocking and mockito wouldn’t help you. So far, I have no problems in verifying behaviour using mockito.
Simple and clean code is one of the fundamental techniques of building successful software, the stuff one learns in the first year of working as a software developer. Mockito shines in that respect.
[...] end of the request, state is all that’s left). Some people argued for some kind of general state machine implementation in the mocking framework. I think this is utterly wrong. If you are writing java [...]
Going over some talks on TechNet and Google Video I’ve discovered points of view about using mock frameworks that I’d never ever expect. For example some people seem to bring up the point that while using mocking frameworks is not inherently bad they do tend to hide the additional complexity that your interfaces might introduce. The reason for that was that if your interface is to big and you’re using Moq instead of creating an instance of it by yourself you will run into unnecessary dependencies and not even see it coming.
Even though I understand those kind of arguments I still believe that both Moq and Mockito are great frameworks and you know what? I use both all the time :D
Keep up the good work!
и всё эе: мне понравилось..
I really like Mockito but I am also writing C#. Do you have any plans to port Mockito to C# or do you know anyone else who is working on a port?
Thanks
According to my knowledge (and you should never trust it too much!) most mocking tools for C# support spying style. That is verify-afterwards flavor. I remember Moq library was quite cool at the time.