ArticleS. MicahMartin.
PreludeToTheMockOff [add child]

Prelude to the Mock Off

You can read David's side of the story here: Stop Mocking Me

He puts it gently... We've actually had some heated arguments about these mocking frameworks and it'a all kinda silly. In the end we're writting good tests for well designed code. Still, these mocking frameworks rub me the wrong way.

Why do I prefer hand-made mocks?
  1. They're simple to write. Yeah it requires a new class but it only takes a couple seconds and it's the most brainless code you'll ever write.
  2. They're simple to use. If I want an instance of a DataEntryView[?] I simple type new MockDataEntryView[?](). With a mocking framework, it takes 3 or 4 lines before I have a usable object.
  3. They're much more flexible. With mocking frameworks you can set returns values and expected method calls but that's about it. Hand-made mocks are limited only by your imagination.
  4. Mocking frameworks are refactoring-challenged. Especially NMock. Rename a method and dozens of tests will break.
  5. Readability. Tests using hand-made mock are easy to read. Tests using mocking frameworks require murky configuration.
  6. Mocking frameworks violate testing convention. Build, Operate, Check. Conventionally, all tests follow this flow. With mocking frameworks the flow becomes, Build, Check, Operate, Verify.
  7. Failures are deceptive with mocking frameworks. When you get a failure in a test using a mocking framework, the line number usually points to a call to Verify. With Rhino it can point to the last line of a using block. Either way, the failure could have been caused by any number of assertions. It’s up to you to figure out which one. With hand-made mocks, line numbers pinpoint the problem by revealing the exact failing assertion.

What do I hope to get out of the Mockoff?
I’ve played with several mocking frameworks before. I hope that by committing to use them for 3 days, I’ll gain insight as to so many people use them. Maybe I’ll find that they improve my productivity and I’ll use them in the future on a regular basis.

What do I expect to happen during the Mockoff?
I’m trying very hard to have an open mind going into this. My stubborn self is expecting 3 days of frustration. My optimistic self is expecting to gain appreciation for mocking frameworks. We’ll see what happens.


 Mon, 31 Oct 2005 12:22:11, SvenGorts[?], Unit Testing With Hand Crafted Mocks
When I started using hand-made mocks, I expected that I would switch to the use of a mocking framework rather rapidly. Perhaps surprisingly this switch never happend and as of today hand-written mocks are still my preferred choice. The article Unit Testing With Hand Crafted Mocks available at summarizes some of my personal experiences.
 Mon, 31 Oct 2005 14:14:35, M. Scott Ford,
I can't argue with some of your points. But you may want to take a glance at NMock2. The code that you write is still refactoring challenged. Which is honestly a refactoring tool limitation in my opinion. (I could not resist!) I think that the mocking code with NMock2 is very human readable. Expectations are setup with Expect.Once.On(object).Method("Method").With(parameter1, parameter2).Will(Return.Value(result)). To me that is very readable, and it is the reason that I use NMock2 in all my tests (Why am I starting to sound like a salesman?)

The errors in this version have been improved as well. Unexpected calls throw at the point that they occur. And all of the unmet expectations are listed as part of any error thrown by NMock2. You still have to include a verify if you want to find out about unfulfilled expectations, but now, at least, it is just one instead of one per mock object.

I do use hand mocks as well. I just don't use them as often. I like to mix and match. I pick the tool that will get me to a finished test that clearly demonstrates its intent the fastest. The "dynamic" mocks have their downsides, but I think that the benefits out weigh the cost. Personally, I like to make it clear what code in a test is "mock" code, and what code is supposed to me part of the class that is getting mocked. I think that the mock tools help keep this separation clear.

But I am sure that these are all arguments you have heard before, so I will shut up now. What I really wanted to do was tell you about NMock2, so here [] is a short article that I wrote comparing NMock and NMock2.

Enjoy the Mockoff! I will enjoy reading the results.
 Tue, 1 Nov 2005 04:37:38, Sagy Rozman, Tons of mock classes
>>> They're simple to write. Yeah it requires a new class but it only takes a couple seconds and it's the
>>> most brainless code you'll ever write.

I agree, and this is exactly why I don't use them. I'm trying to write most of my tests as interaction based tests. At first I was going for the hand made mocks approach, but soon I discovered that the test.utils.mocks package was getting quite large. There where lots of mocks and it was getting out of control. When I started to refactor this code I suddenly realized that I was building j/nmock all over again. I then stopped and learned all there is to know about using these libs.
Today I use the mock librarys more than hand made mocks.
 Tue, 1 Nov 2005 04:43:23, David Chelimsky, re: Unit Testing With Hand Crafted Mocks
Sven - I read your article. I like the idea of different types of substitutes. I can imagine that they do a lot to clarify the tests that use them. I'm going to experiment with that as part of my experiment.
 Thu, 3 Nov 2005 03:45:47, IsmetKahraman[?],
Sometimes, interacting with an API full of static methods does not allow to mock these classes. In these times, virtualmock really helps. Adding new behavior (here mocking behavior) by means of aspects is a different and a helpful approach. But for the time being, I prefer EasyMock[?] in my TDD efforts. Simple, once accustomed it is a very natural way of dealing with external interfaces.
 Sat, 12 Nov 2005 22:00:03, Steve Eichert, Have you tried Rhino Mocks?
Rhino Mocks gets rid of the hard coded strings everywhere. I haven't actually used it as I'm much more of a hand crafted mock guy, however, it does look interesting.
 Wed, 14 Dec 2005 09:22:37, Paul Pagel,
I have been using used Rhino mocks lately, which have solved some of the objections to mocks you listed. One thing I have noticed about hand mocks is they end up with logic in them. Often mock classes, as they evolve, will contain logic around different results which is neccessary for the return type or to simulate minimal behavior for the mock to be useful. This logic becomes a lie, as it is not updated with the code, so when the production code gets changed, the tests using the mocks will still pass. The fact there is no executable accountability as a mocking framework would provide makes hand mocks dangerous unless they are bare bones. A mocking framework takes away the temptation, as they can only be bare bones mocks.
 Wed, 14 Dec 2005 09:36:09, David Chelimsky, mostly stubs....
There is a distinction that "mockists" make between mocks and stubs. They are both fakes, but a stub is a class that you set up to behave in a known way when the class under test interacts with it - returning a known value in response to a query, for example. A mock records messages it gets from the class under test and reports back against expectations you set in advance. Whether you're hand-mocking or rhino-mocking or any-framework-mocking - the problem of fakes becoming lies as the real classes change is related more to stubs (predefined behavior of collaborator) than mocks (verification of behavior of class under test).

That said, my biggest issue is the extra classes it produces. I'm in the middle of (gradually) splitting a hierarchy into two separate hierarchies. The existence of hand made mocks for every one of the production classes doubles the effort involved in this separation. Hand made mocks seem to be bound to static hierarchies. Tool generated mocks seem to be bound to the classes they mock and that's all.
 Wed, 11 Jan 2006 14:04:57, David Kreth Allen, So, Micah, what is your impression at this point?
Are you more likely to use mock tools now?
Any suggestions about when to favor one over the other?