[rspec-devel] If you set an expectation on something that's already stubbed, should it return the stubbed value?
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
> it "should check the balance" do
> 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.
> - 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
> - 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?"
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel