El 29/6/2009, a las 9:33, Matt Wynne escribió:
On 28 Jun 2009, at 23:02, Wincent Colaiuta wrote:
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.
If I understand this correctly, there was only one call from
Controller -> Comment that you wanted to test; the other one was a
call from Comment -> Comment that happened as a side-effect.
Exactly.
So I'm wondering: if you'd returned a fake (mock, stub, whatever)
comment from your stubbed Comment.find, would that have solved the
problem?
Yes, but there's something about that that felt somehow harder than it
should be.
I mean, I had a working, dead-simple controller spec. I made an
unrelated change in the model, and the controller spec broke.
Returning a fake would certainly fix the breakage, but the spec would
no longer be dead-simple and it somehow feels like one step foward,
two steps back, that due to innocuous model changes I have to increase
the complexity of my controller tests.
So what I'm really pining for is the ability to say "expect this
message, but don't return fakes -- just proxy the message through and
return the real return value -- and don't worry about any other
messages".
Cheers,
Wincent
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
