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 http://www.refactoring.be/articles/mocks/mocks.html summarizes some of my personal experiences.

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 [http://vaderpi.scottandlaurie.com/blog/?p=185] is a short article that I wrote comparing NMock and NMock2.

Enjoy the Mockoff! I will enjoy reading the results.

>>> 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.

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.

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.

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.

http://www.ayende.com/projects/rhino-mocks.aspx

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.

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.

Are you more likely to use mock tools now?
Any suggestions about when to favor one over the other?