El 28/6/2009, a las 23:04, Matt Wynne escribió:
On 28 Jun 2009, at 13:07, Wincent Colaiuta wrote:
I've had one of my recurring doubts about test doubles come up again.
The full post is here but I'll abbreviate the content in this
message in any case:
https://wincent.com/blog/thinking-about-switching-to-rr
Basically, in one of my controller specs I wanted to verify that
the following line was being called and doing the right thing:
@comment = Comment.find params[:id]
I had a mock for this set up, but it broke when unrelated code in
the model was modified (a complex callback which itself called
Comment.find).
I'd like to know more about how this happened. How did the model
object's behaviour leak into the controller spec?
This was a spec for the controller's "update" action, which does a
"save" on the record. At one point a change was made to the model to
do some complex updates in the after_save callback, and these involved
doing another Comment.find call, but with different parameters.
In my ideal test-double framework, I'd like to really assert two
things about the line of code in question:
1. That Comment.find gets called with a specific param at some
point in time.
2. That the @comment instance variable gets the expected value
assigned to it.
So why not use
Comment.stub!(:find).with(123).and_return(mock(Comment))
Because there are actually two "find" calls here:
- the one I actually care about
- the other one in the after_save callback which is irrelevant to the
controller
I original used "should_receive", not "stub", so RSpec complained
about getting "find" with the unexpected parameters. If I change to
"stub" then I'm losing my assertion (no longer checking that the
message gets sent), injecting a different return value (adding
complexity), for no visible benefit (may as well just throw away the
expectation).
Cheers,
Wincent
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
