Do we really need isolation frameworks to create stubs?

Question

I have read this: http://martinfowler.com/articles/mocksArentStubs.html My concepts about a stub and a mock are clear. I understand the need of isolation frameworks like moq, rhinomocks and like to create a mock object. As mocks, participate in actual verfication of expectations. But why do we need these frameworks to create stubs. I would rather prefer rolling out a hand created stub and use it in various fixtures.

Answer 1

Strictly speaking, no, you do not need an isolation framework to create stubs. In fact, Microsoft even has a Stubs Framework that only generates stubs, not mocks.

I've never written an isolation framework myself, but it would seem that it once you have object mocking in place, stubs would be a breeze to create. That might be the main reason that most/all isolation frameworks include stub objects.

In regards to your last sentence ("I would rather prefer rolling out a hand created stub and use it in various fixtures"), have you actually tried that on any sizable project? Sure, maybe you have an interface with a single method that returns a nullable bool -- you only have to write three stubs for that interface, and that's not so bad.

But once you start looking at dozens of interfaces and classes to stub, it simply becomes a mess to keep track of all the different stubs. If you are using each stub in several tests, you can certainly justify hand-writing a stub and putting it aside; but when you only use one particular stub once or twice, it's much easier to keep it as an "anonymous" stub directly generated by the framework, for simplicity's sake.

Answer 2

Have you tried using a library like Rhino Mocks for a day or two before deciding that hand-rolled stubs is a better option?

@chibacity: The whole idea about mocking libraries is to avoid implementations. If I only need to set a single property's value, I don't want to create a whole implementation of an interface. Calling code like

MyObj obj = MockRepository.GenerateStub<MyObj>();
obj.MyProperty = 33;

seems much simpler to me. Not to mention situations where I only need a dumb stub to be passed as a parameter where I don't care what happens to it (so no set up is required).

This doesn't mean you shouldn't roll out your own stubs for more complex scenarios, but in my experience such cases are rare.

My recommendation is to learn how to use a good mocking library (like Rhino) with all its little tricks, my bet is that you'll soon learn to appreciate the reasons for its existence.

Answer 3

After using mocking frameworks for a while, I have found that my code design takes on a totally different slant. This slant seems to be directed more in an interaction style. In other words, I become more interested in messages and behavior than state. My objects become services rather than stateful objects as would happen when using stubs. With stubs I end up passing state around to other objects.

The problem for me then becomes more of creating abstraction layers. I have to question whither something should be interacting at certain levels. This helps with creating that 'Last responsible Moment'. So I end up with objects that have producers and consumers. And everything in between is just message channels.

I hope this helps.