On 22/11/06, <b class="gmail_sendername">Jason Watkins</b> <<a href="mailto:jason@jasonwatkins.net">jason@jasonwatkins.net</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sure. Let's say I have some ruby objects that do i/o with a<br>distributed system. In the development environment the remote system<br>isn't available. That gives me two conventional choices:<br><br>1.) use a configuration boolean set somewhere to early out
<br>2.) parameterize the constructor to use dependency injection of a mock<br><br>Using stubba to override the object directly could be seen as a more<br>implicit version of #2.<br><br>While I understand various folks might object to it on all manner of
<br>philosophical grounds, it's something I'd like to be able to do from<br>time to time.</blockquote><div><br>I think the objections are more practical than philosophical. If you are new to mocking, I suggest you read "Mock Roles, not Objects" (
<a href="http://www.jmock.org/oopsla2004.pdf">http://www.jmock.org/oopsla2004.pdf</a> by <font face="Times" size="3"><span style="font-size: 15px; font-family: Times;">Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes. Here is a particularly relevant section.
</span></font><br><br><blockquote>4.1 Only Mock Types You Own<br>Mock Objects is a design technique so programmers should only<br>write mocks for types that they can change. Otherwise they cannot<br>change the design to respond to requirements that arise from the
<br>process. Programmers should not write mocks for fixed types,<br>such as those defined by the runtime or external libraries. Instead<br>they should write thin wrappers to implement the application<br>abstractions in terms of the underlying infrastructure. Those
<br>wrappers will have been defined as part of a need-driven test.<br>We have found this to be a powerful insight to help programmers<br>understand the technique. It restores the pre-eminence of the<br>design in the use of Mock Objects, which has often been
<br>overshadowed by its use for testing interactions with third-party<br>libraries.<br></blockquote>There is nothing to stop you using Mocha in your development environment, but there are a few issues you should think about...
<br><br>1) No convenience methods for creating mocks or stubs - you would have to directly instantiate them using something like <span style="font-family: courier new,monospace;">Mocha::Mock.new</span><br><br></div></div>
2) <span style="font-family: courier new,monospace;">$stubba</span> global variable is not defined - you would have to do something like <span style="font-family: courier new,monospace;">$stubba = Mocha::Central.new</span>
<br><br>3) No auto-verification of expectations - you would have to explicitly call the <span style="font-family: courier new,monospace;">verify</span> method on traditional mock/stub objects and <span style="font-family: courier new,monospace;">
$stubba.verify_all</span> to verify expectations on real objects<br><br>4) Probably most importantly, no rolling back of stubbing - you would have to explicitly rollback by calling $stubba.unstub_all<br>
<br>
One of the problems you will run into will be when to call the above hooks in your development environment.<br><br>Some of these hooks are not considered parts of the published API and so are subject to change.<br><br>All the above is written in the context of the HEAD revision in svn and not the latest gem.
<br><br>I hope that makes some kind of sense. <br>-- <br>James.<br><a href="http://blog.floehopper.org">http://blog.floehopper.org</a>