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

Blake Watters blake at near-time.com
Fri Sep 12 11:12:28 EDT 2008


If I approached RSpec without any existing knowledge, my assumption would be
that the stubbed method would return the value. Anything we can do to
preserve that sort of learning via discovery is a win.

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?
> Pat
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080912/e2c5a5ee/attachment.html>

More information about the rspec-devel mailing list