What is the appropriate way to stub out (and put an expectation on
Object#send), without getting warnings from the Rspec mock library?
Scott
What is the appropriate way to stub out (and put an expectation on
Object#send), without getting warnings from the Rspec mock library?
Scott
On Dec 6, 2007, at 4:41 PM, David C. wrote:
Error please?
Not an error, just a warning. And I should have written my
description better. Basically, I wanted to make sure that my library
didn’t call send, but instead send. I tried something like this:
before :each do
@caller = Object.new
@caller.stub!(:send).and_raise
@caller.stub!(:__send__)
end
it "should be able to send the message with __send__" do
@caller.should_not_receive(:send)
@caller.should_receive(:__send__)
@attributes.to_new_class_instance({}, @caller)
end
The @caller object is a sort of mock object. I would have used a
real mock object, except that stubbing send on a mock object didn’t
seem to do anything.
The warning was this:
./usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.8/lib/spec/mocks/
proxy.rb:99: warning: redefining `send’ may cause serious problem
Just wondering about what you would recommend for this. Let me know
if you need more context.
Scott
On Dec 6, 2007 3:37 PM, Scott T. [email protected]
wrote:
What is the appropriate way to stub out (and put an expectation on
Object#send), without getting warnings from the Rspec mock library?
Come on Scott - you know better than that
Error please?
On Dec 6, 2007, at 5:12 PM, David C. wrote:
Object#send), without getting warnings from the Rspec mock
before :each do
@attributes.to_new_class_instance({}, @caller)
proxy.rb:99: warning: redefining `send’ may cause serious problemI LOVE that it says “may cause serious problem” - not “problems”
Anyhow - I’m not sure what we can do about that. RSpec’s stubs work by
redefining existing methods. Ruby doesn’t want you to do that with
send. For the moment, there’s no way around it, but I’m not even
sure what we could change in RSpec to make it work. Any ideas?
Ah - so it’s actually something ruby does, and not the mock library.
I hadn’t realized that.
I’m not sure this is the best idea, but we could actually remove the
warning:
def execute_silently(&blk)
old_warning_level = $VERBOSE
$VERBOSE = nil
yield
$VERBOSE = old_warning_level
end
(or I could do this myself, in my own specs)
Scott
On Dec 6, 2007 4:08 PM, Scott T. [email protected]
wrote:
@caller.stub!(:send).and_raise
The @caller object is a sort of mock object. I would have used a
real mock object, except that stubbing send on a mock object didn’t
seem to do anything.The warning was this:
./usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.8/lib/spec/mocks/
proxy.rb:99: warning: redefining `send’ may cause serious problem
I LOVE that it says “may cause serious problem” - not “problems”
Anyhow - I’m not sure what we can do about that. RSpec’s stubs work by
redefining existing methods. Ruby doesn’t want you to do that with
send. For the moment, there’s no way around it, but I’m not even
sure what we could change in RSpec to make it work. Any ideas?
On Dec 6, 2007, at 5:25 PM, David C. wrote:
On Dec 6, 2007 3:37 PM, Scott T.
[email protected] wrote:What is the appropriate way to stub out (and put an
expectation on
Object#send), without getting warnings from the Rspec mock
library?
…
(or I could do this myself, in my own specs)
I’d be happier if you did that yourself. I don’t want RSpec to be in
the habit of hiding warnings.
Yep. I don’t disagree with you (especially now that I know that the
warning comes from ruby itself). Originally I thought that maybe the
mock library used send, and issued a warning if you tried to stub
it.
Scott
On Dec 6, 2007 4:22 PM, Scott T. [email protected]
wrote:
[email protected] wrote:
Not an error, just a warning. And I should have written my
it “should be able to send the message with send” dosure what we could change in RSpec to make it work. Any ideas?
yield
$VERBOSE = old_warning_level
end(or I could do this myself, in my own specs)
I’d be happier if you did that yourself. I don’t want RSpec to be in
the habit of hiding warnings.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs