Hi guys. Quite happy with mocha for testing. It''s been a bit of an eye opener for me, and I expect to begin using it heavily. One other thing I''d like to do is stub out particular class methods in development. Is there a way I can do this with mocha? Jason
On 21/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:> > Quite happy with mocha for testing. It''s been a bit of an eye opener > for me, and I expect to begin using it heavily.Cool. One other thing I''d like to do is stub out particular class methods in> development. Is there a way I can do this with mocha? >Why do you want to do it? Can you give a concrete example? While it would be technically possible, I wouldn''t recommend it. -- James. http://blog.floehopper.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061122/f2df212e/attachment.html
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. Jason On 11/22/06, James Mead <jamesmead44 at gmail.com> wrote:> On 21/11/06, Jason Watkins <jason at jasonwatkins.net> wrote: > > Quite happy with mocha for testing. It''s been a bit of an eye opener > > for me, and I expect to begin using it heavily. > > Cool. > > One other thing I''d like to do is stub out particular class methods in > > development. Is there a way I can do this with mocha? > > > > Why do you want to do it? Can you give a concrete example? > > While it would be technically possible, I wouldn''t recommend it. > > -- > James. > http://blog.floehopper.org > _______________________________________________ > mocha-developer mailing list > mocha-developer at rubyforge.org > http://rubyforge.org/mailman/listinfo/mocha-developer > >
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
> I think the objections are more practical than philosophical. If you are newRight. I wasn''t interested in this particular debate.> Some of these hooks are not considered parts of the published API and so are > subject to change.Right. I''ve gotten this far on my own. My bringing it up is to suggest that perhaps it should be part of the API. If you feel "you shouldn''t do that, so I''m not going to help you do it", then another justification would be so that mocha isn''t wired so directly to Test::Unit. Another example would be exploratory programing. It looks like I''ll just write my own. Thanks, Jason
On 22/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:> > > I think the objections are more practical than philosophical. If you are > new > > Right. I wasn''t interested in this particular debate.I''m sorry I appear to have touched a nerve. I was merely trying to pass on advice that I have found useful in my own work.> Some of these hooks are not considered parts of the published API and so > are > > subject to change. > > Right. I''ve gotten this far on my own. My bringing it up is tosuggest that perhaps it should be part of the API. As I tried to explain, I think one of the main problems in doing this is finding somewhere to call the hooks I mentioned in my last email. If you take the view that you only want to use stubs and have no requirement for verifying expectations, you still need to decide when to create the $stubbaglobal variable and when to revert the stubbed objects/classes to their original state. Do you have some constructive ideas on this front? If you feel "you shouldn''t do that, so I''m not going to help you do> it", then another justification would be so that mocha isn''t wired so > directly to Test::Unit.I think you''re being harsh when you say that "I''m not going to help you" when I gave you the four point explanation below. You should also note that the HEAD version of Mocha already has a Standalone module which is not wired directly to Test::Unit, to allow simple integration with other testing frameworks. 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 Another example would be exploratory programing. It looks like I''ll just write my own. Good luck. -- James. http://blog.floehopper.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061123/6ee881b1/attachment.html