On Jul 29, 2008, at 12:31 AM, Steve wrote:
Pat Maddox wrote:
etc. It's super weird that it works in every other place but not
here. So I'd start from the tiniest thing possible and add lines
until you find one that breaks it.
Pat
So I went through and took the whole thing apart. It turns out that
it is/was a stub issue(just not quite what expected). Prior to
calling the shared describe Reservation.find was stubbed to return
[]. I didn't realize that internally the fixtures collections used
find. Now that I do, it all makes sense; since it's just doing what
I told it to.
So in a way my original question still stands. Is there a way to
"unstub" something? Because I don't see a way around this unless I
can do that. Thanks for your help.
Of course there is a way - the question is, do you really want to use
it?
Here's how the test suite sets up stubs:
1. you say, stub object foo with method bar, returning baz
2. rspec aliases the original method, and then redefines it bar on foo
to return baz
3. your test case ends, and then rspec goes back, and re-aliases the
method to it's original definition.
So yes, you could call the un-stub'ed method (which I believe rspec
calls #proxied_by_rspec_#{method_name}), although I think it'll be
ugly and confusing. But, if you really want to override the
behaviour, I'd suggest defining something like this:
class Object
def original_stub(method_name, *args, &blk)
self.send("proxied_by_rspec_#{method_name}", *args, &blk)
end
end
But, I think the best result is just to duplicate the stub.
Scott
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
