search for: reevoo

Hi all ! Running this: @payout = stub_everything(:id => 141) Payout.stubs(:find).with(@payout.id).returns(@payout) Generates this warning: ./test/functional/payouts_controller_test.rb:22: warning: Object#id will be deprecated; use Object#object_id What am I missing ? :id is a fairly frequent method to override in Rails-based applications. I''m using Mocha from

We''re using Mocha stubs to stub out a slow-performing network request in a Test::Unit class. But naturally, we don''t want to stub it out in the few tests that actually verify the functionality of that network request. Is there a way to do the stub in "setup", but override it for the few tests that need the original functionality? (I realize that in this case, the

Hilarious => http://www.reevoo.com/blogs/bengriffiths/2006/12/12/rspec-video/

I''m writing quite a few specs lately that use Ruby''s Timeout::timeout functionality, making sure that timeout errors are properly handled and everything flows right when some command line tools timeout. I like being able to use Mocha''s #returns right now to force a method to raise a TimeoutError, but I know that usage is going away at some point. I''d like to

Hi guys, I''ve just been reading Martin Fowler''s article re mock versus stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where he compares traditional TDD testing techniques with mock based testing. I''d be interested in comments from a ruby on rails perspective in terms of this and Mocha? For example: a) Do you see Mocha as a robust way to test Ruby

Hi folks. So I''m using mocha on a ruby project, and I really like it. One thing I''ve noticed is that it can be a bit "surprising" when I''m mocking methods that don''t exist on an object, and I think there''s an easyish fix. At the moment, you use sheep = mock() to create a mock sheep. What I''d like to do is something like sheep =

...t would make far more sense to break it down into ArticleViewTest, ArticlePostTest, FailedArticleCreate test and SuccessfulArticleCreate, because each of those represent different contexts, or fixtures. I''m quite keen on Ben Griffiths'' testing approach outlined here<http://www.reevoo.com/blogs/bengriffiths/2005/06/24/a-test-by-any-other-name/>and have also been looking into Dave Astels'' RSpec <http://rspec.rubyforge.org/> and have to agree with the idea of testcases being bound by fixtures. If you have test methods that require common setups, the code should b...

Cool. Thanks for letting me know. On 21 Jul 2007, at 09:20, Chris O''Sullivan wrote: > Heya James, > > I thought you''d like to know that Mocha featured in the latest > Railscasts. > > Check it out here: http://railscasts.com/episodes/60 > > -Chris >

Mocha 0.5.2 now tagged in svn repos. Begin forwarded message: > From: James Mead <james.mead at mail.com> > Date: 21 July 2007 10:21:11 BDT > To: Zach Dennis <zach.dennis at gmail.com> > Subject: Re: Tagging Mocha 0.5.x > > Hi Zach, > > Thanks for pointing that out. I''ve just tagged 0.5.2 and will try > to retrofit earlier tags as soon as I can.

Hi Antonio, My environment is OS X 10.4.8. Thanks a lot for looking into the problem. Please let me know if I can do anything to help. I have had problems previously with tar including Mac resource fork files. Could this be what is causing your problem? James. On 24 Jul 2007, at 20:42, Antonio Terceiro wrote: > Hi James, > > First of all, thanks for mocha, it''s a really