[rspec-devel] If you set an expectation on something that's already stubbed, should it return the stubbed value?

David Chelimsky dchelimsky at gmail.com
Fri Sep 12 10:48:56 EDT 2008

On Fri, Sep 12, 2008 at 9:44 AM, Pat Maddox <pergesu at gmail.com> wrote:
> Hey guys,
> Here's a pretty simple spec
> describe AccountService do
>  before(:each) do
>    @account = stub("account", :balance => 12345)
>    @service = AccoutnService.new
>  end
>  it "should check the balance" do
>    @account.should_receive(:balance)
>    @service.get_balance(@account)
>  end
> end
> Ignore the fact that it's totally lame :)
> Right now, in the example, @account.balance will return nil.  Any
> other specs that call it will get back 12345.  What do you guys think
> about making it return the same value by default, instead of nil?  So
> basically, instead of totally shadowing that method, we simply tighten
> up the constraints on the mock object by adding an expectation.
> Pros:
> - Less verbose - it expresses intent better, I think.  You don't
> really care what it returns in that case.  Just that it gets that
> method called, and everything works
> - No duplication.  I can't think of a single instance where I stubbed
> a call, and then in my expectation I wanted it to return nil.  I
> *always* duplicate it
> Cons:
> - Less verbose :)  maybe some people would think it's not explicit enough?
> Personally, I'm all for it.  What do you guys think?

My instinct is +1, but I want to think about it a bit. My only concern
would be "what is the risk of breaking existing examples?"

> Pat
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

More information about the rspec-devel mailing list