Let’s start from the beginning. Lately, I’ve been quite busy (perhaps lazy is a better word, though) and I couldn’t find time to sharply reply to few interesting blog articles. Dan North became a friend of Mockito and wrote about the end of endotesting. His post sparked few interesting comments. Steve Freeman wrote:
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.
Well, I wrote Mockito because I needed a simple tool that didn’t get in the way and gave readable & maintainable code.
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.
When something is hard to test it gives excellent feedback about the quality of the code under test. If you’re a developer then your main responsibility is to respond to this feedback. jMock guys came up with this excellent metaphor: “you should listen to your tests“.
I wish there was a mocking framework which gave positive feedback when the production code was clean but gave negative feedback when the design was weak. When I used jMock I had an impression that the feedback is negative all the time, regardless of the quality of the design. Good code or bad code – the syntactic noise was present in every test. If the feedback is always negative how do I know when the design is weak?
Patrick Kua writes in his blog:
That’s why that even though Mockito is a welcome addition to the testing toolkit, I’m equally frightened by its ability to silence the screams of test code executing poorly designed production code
Mockito tends to give positive feedback. It keeps the syntactic noise low so the tests are usually clean regardless of the design. If the feedback is always positive how do I know when the design is weak?
So, what brings out design issues better – jMock or Mockito? Go figure: the first gives too much noise, the second is too silent. Before you join the debate, please note that the discussion is fairly academic. After all it is nothing else but looking at the mocking syntax and thinking how it influences the production code.
Can we really say that the quality of the production code is different when tested with different mocking framework? We strive to build fabulous mocking frameworks but high quality code is the result of skill, experience and so much more than just a choice between Mockito or jMock, TypeMock or RhinoMock, expectations before or after, etc.
At this moment, for unknown reason, one of the readers suddenly remembered the test he wrote last week. The one that required 17 mock objects. Which one? The one where the mock is told to return the mock, to return the mock, to return the mock, to return the mock, to return the mock. Then assert something equals seven. Oh yeah, that one! The test looked quite horrible but hey, you know what they say, better bad test than no test. Obviously, this ugly jMock made the test unreadable. The design was absolutely flawless because there were many patterns used. Fortunately, the team started using Mockito the following week! The rumor was that Mockito test became unreadable only if the number of mocks per test (MPT) exceeded 25. Awesome! Next week, the eager developer was unpleasantly surprised with Mockito. The test with MPT 17 was looking as horrible. To solve the problem, the team decided to install EasyMock.
I haven’t participated in enough java projects but I dare to say this: The quality of design was no better when we did hand mocking, EasyMocking, jMocking or drinking Mockitos. Somehow drinking Mockitos was much pleasant experience, maybe because it’s darn good drink.
No hangover guaranteed. (Eastern Europeans only).