Mock libraries, Object#send, and Object#__send__

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 :slight_smile:

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 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?

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” do

sure 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.

| Privacy Policy | Terms of Service | Remote Ruby Jobs