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

[Zach Dennis]

On Fri, Sep 12, 2008 at 10: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?

-1. This works against clearly expressing the intent in each example.
I vote for keeping the explicit values used by an example (if that is
what is being tested) inside each example. Clarity over saving a few
keystrokes on this one,


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com