[mocha-developer] stubbing in development environment

James Mead jamesmead44 at gmail.com
Wed Nov 22 09:52:41 EST 2006


On 22/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:
>
> Sure. Let's say I have some ruby objects that do i/o with a
> distributed system. In the development environment the remote system
> isn't available. That gives me two conventional choices:
>
> 1.) use a configuration boolean set somewhere to early out
> 2.) parameterize the constructor to use dependency injection of a mock
>
> Using stubba to override the object directly could be seen as a more
> implicit version of #2.
>
> While I understand various folks might object to it on all manner of
> philosophical grounds, it's something I'd like to be able to do from
> time to time.


I think the objections are more practical than philosophical. If you are new
to mocking, I suggest you read "Mock Roles, not Objects" (
http://www.jmock.org/oopsla2004.pdf by Steve Freeman, Nat Pryce, Tim
Mackinnon, Joe Walnes. Here is a particularly relevant section.

4.1 Only Mock Types You Own
Mock Objects is a design technique so programmers should only
write mocks for types that they can change. Otherwise they cannot
change the design to respond to requirements that arise from the
process. Programmers should not write mocks for fixed types,
such as those defined by the runtime or external libraries. Instead
they should write thin wrappers to implement the application
abstractions in terms of the underlying infrastructure. Those
wrappers will have been defined as part of a need-driven test.
We have found this to be a powerful insight to help programmers
understand the technique. It restores the pre-eminence of the
design in the use of Mock Objects, which has often been
overshadowed by its use for testing interactions with third-party
libraries.

There is nothing to stop you using Mocha in your development environment,
but there are a few issues you should think about...

1) No convenience methods for creating mocks or stubs - you would have to
directly instantiate them using something like Mocha::Mock.new

2) $stubba global variable is not defined - you would have to do something
like $stubba = Mocha::Central.new

3) No auto-verification of expectations - you would have to explicitly call
the verify method on traditional mock/stub objects and $stubba.verify_all to
verify expectations on real objects

4) Probably most importantly, no rolling back of stubbing - you would have
to explicitly rollback by calling $stubba.unstub_all

One of the problems you will run into will be when to call the above hooks
in your development environment.

Some of these hooks are not considered parts of the published API and so are
subject to change.

All the above is written in the context of the HEAD revision in svn  and not
the latest gem.

I hope that makes some kind of sense.
-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061122/8815c9d3/attachment-0001.html 


More information about the mocha-developer mailing list