[rspec-devel] If you set an expectation on something that's already stubbed, should it return the stubbed value?
zach.dennis at gmail.com
Fri Sep 12 12:22:44 EDT 2008
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
> 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?
-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,
More information about the rspec-devel