Hi David,
> I've been thinking of deprecating the and_xxx methods in rspec-2. Does
> anybody think that's an awful idea?
Well I can tell you that this syntax you demonstrated:
> foo.stub(:bar) { "return value" }
> foo.stub(:bar) { raise SomeError }
> foo.stub(:bar) { yield "value" }
> foo.stub(:bar) { throw :value }
is so much clearer to me, intuitive, and friendly....
Thank you very much for your explanations, they really help-- I finally get the
whole stub / should_receive... The only thing that is still a bit fuzzy to me,
is knowing when to use one over the other.
With the case of should_receive, I am having a hard time imagining a useful
test, because everything I am thinking of-- is something like:
def index
@blogs = Blog.all
...
end
#
Blog.should_receve(:all) { @list_of_blogs }
...
And that to me, seems like a pointless test because it's evident visually that
the code is fine, flawless and will work exactly as expected. But I probably
am missing something...
Now, one other thing I might ask you to explain, since you do such a great job,
is what are the differences between "mock" "mock_model" and "should_receive"
since they all are "mocking"...?
Patrick J. Collins
http://collinatorstudios.com
On Sat, 20 Mar 2010, David Chelimsky wrote:
> On Sat, Mar 20, 2010 at 2:28 AM, Patrick J. Collins
> <patr...@collinatorstudios.com> wrote:
> > 4. You do .stub! ........... This is where I get really
> > confused. From the peepcode screencast that I have watched
> > several times, he explained that stubbing is the same as
> > mocking-- except there is no expectation of what it returns.
> >
> > That made sense when he said it, but in all the examples I've
> > seen with code (including yours), there is this .and_return at
> > the end.. Which as far as I can tell, is an expectation.. I
> > mean, you are asking it to return a specific thing-- that is
> > an expectation is it not? Or does expectation really mean
> > something else in this context?
>
> .and_xxx is admittedly confusing, as evidenced by your confusion.
> These are _not_ expectations, they are merely configuration.
>
> When you say
>
> foo.stub(:bar).and_return('this value')
>
> you're saying: hey, foo, you might receive the bar() message. If you
> do, return "this value".
>
> When you say
>
> foo.should_receive(:bar).and_return('this value')
>
> you're saying: hey, foo, you _should_ receive the bar() message. If
> you do, return "this value". If you don't, raise an ExpectationNotMet
> error.
>
> Neither are saying: hey, foo, you should return "this value", and if
> you don't, I'll consider it a failure.
>
> There are also and_raise, and_yield, and and_throw methods that
> operate similarly. They are instructions to the object that allow you
> to control how it behaves so you can set expectations on other objects
> as to how they should respond. Make sense?
>
> There is an alternate syntax that I'm using nearly exclusively at this
> point, which is to pass a block along with the stub() and
> should_receive() messages:
>
> foo.stub(:bar) { "return value" }
> foo.stub(:bar) { raise SomeError }
> foo.stub(:bar) { yield "value" }
> foo.stub(:bar) { throw :value }
> foo.should_receive(:bar) { "return value" }
> foo.should_receive(:bar) { raise SomeError }
> foo.should_receive(:bar) { yield "value" }
> foo.should_receive(:bar) { throw :value }
>
> As you can see, there is much less API to worry about here. You're
> just supplying an implementation.
>
> This approach also works with scoped arguments:
>
> input = Input.new
> calculator = Calculator.new(input)
> calculator.should_receive(:add).with(1,2) { 3 }
> input.type("1", "+", "2", "Enter")
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
