#536 √ resolved
joshuakrall (at pobox)

nested should_receive after stub! is broken

Reported by joshuakrall (at pobox) | September 19th, 2008 @ 08:40 AM | in No-Milestone-Assigned

I just pulled from the github head, after having been frozen on 1.1.4... and some of my tests broke in a strange way. I've tried to diagnose it on my own... to no avail.

Here's a snippet from one of my broken specs:


describe Pricing::Subengine::Tier::Verify do

  before(:each) do
    @engine = Pricing::Subengine::Tier::Verify.new()
    @engine.stub!(:log_message)
    @engine.stub!(:tier).and_return(1.0)
    @engine.stub!(:volume).and_return(1.0)
    @engine.instance_variable_set('@subengines',[])
  end

  describe 'should set the default option tier' do
    it 'if volume & tier are nil' do
      @engine.should_receive(:tier).and_return(nil)
      @engine.should_receive(:volume).any_number_of_times.and_return(nil)
      @engine.send('default_options_engine')[:tier].should == 0
    end
  end
end

This test passed perfect before, but now it is breaking. By putting in some debugging print-outs, I've determined that :volume is being set to 1.0... as though the stub! in the top-level before(:each) is taking effect, but the should_receive is not.

Interestingly... if I delete the any_number_of_times from the :volume expectation, then I get a different behavior (still broken!). In this case, my printouts inside the code show this: p "volume: #{volume}" p "volume class: #{volume.class}" p "volume inspect: #{volume.inspect}" p "volume nil?: #{volume.nil?}" volume: volume class: Float volume inspect: 1.0 volume nil?: false

Any ideas? Am I doing something wrong here? Thanks!

Comments and changes to this ticket

  • joshuakrall (at pobox)

    joshuakrall (at pobox) September 19th, 2008 @ 08:41 AM

    Sorry... the formatting in the last paragraph is a mess...

    In this case, my printouts inside the code show this:

    
p "volume: #{volume}"
p "volume class: #{volume.class}"
p "volume inspect: #{volume.inspect}"
p "volume nil?: #{volume.nil?}"
volume:
volume class: Float
volume inspect: 1.0
volume nil?: false
  • David Chelimsky

    David Chelimsky September 19th, 2008 @ 02:31 PM

    • → State changed from “new” to “open”
    • → Tag changed from “mocks nesting rspec” to “mocks regression”
    • → Assigned user changed from “David Chelimsky” to “Pat Maddox”

    I don't think it's because of nesting. We recently introduced a change that intentionally uses a previously stubbed value when the expectation doesn't supply one. That's likely the cause, though it is a regression, not an intentional change in behaviour.

  • David Chelimsky

    David Chelimsky September 19th, 2008 @ 05:45 PM

    (from [d868cf0ab0338fd7842669186c2e453cd564470b]) Fixed bug when should_receive(:foo).any_number_of_times is called after similar stub Fixes LH[#536] http://github.com/dchelimsky/rsp...

  • Pat Maddox

    Pat Maddox September 19th, 2008 @ 05:46 PM

    • → State changed from “open” to “resolved”

    whoopsy daisy. Fixed in http://github.com/dchelimsky/rsp...

  • David Chelimsky

    David Chelimsky September 19th, 2008 @ 05:47 PM

    Thanks for the quick turnaround!

  • joshuakrall (at pobox)

    joshuakrall (at pobox) September 19th, 2008 @ 06:40 PM

    Wow, that was very fast! Thanks... you guys rock.

  • Michael Granger

    Michael Granger October 24th, 2008 @ 02:57 AM

    This fix seems to have broken the case where you have the same situation but don't specify #any_number_of_times with the #should_receive.

    I've attached a patch to any_number_of_times_spec.rb (even though I suspect that's not where it should live) that demonstrates the breakage with another example.

  • David Chelimsky

    David Chelimsky October 24th, 2008 @ 04:50 AM

    Hi Michael,

    This is actually behaving correctly. The default number of times for a mock message is 1, so these three are equivalent:

    
obj.should_receive(:msg)
obj.should_receive(:msg).once
obj.should_receive(:msg).exactly(1).time

    So the second call in your example fails as it should.

    Also, in the future, since lighthouse doesn't allow non-project-members to re-open tickets, please open new tickets if you feel a ticket should be re-opened. Comments added after a ticket is closed are very likely to get lost in the shuffle.

    Cheers, David

Please Login or create a free account to add a new comment.

You can update this ticket by sending an email to from your email client. (help)

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Behaviour Driven Development for Ruby.

Shared Ticket Bins

People watching this ticket

Attachments

Tags