On 9/3/07, Rodrigo Alvarez Fernández <[EMAIL PROTECTED]> wrote:
> On 9/3/07, Peter Marklund <[EMAIL PROTECTED]> wrote:
> > > 2) Chained stubs/expectations
> > >
> > > mock.stub!(:valid?).and_return(false)
> > > mock.stub!(:valid?).and_return(true).after_receiving
> > > (:save).and_return(true)
> >
> > On first look, that last line is pretty hard to read. I think I
> > understand the intention now, but I'm not sure it harmonizes with the
> > "Clarity over Cleverness" motto.
> >
> I understand that there are maybe too many method calls there, but it
> would be a nice feature.
>
> Another approach could be using blocks:
>
> mock.stub?(:save).and_return(true) do |saved_mock|
> saved_mock.stub!(:valid?).and_return(true)
> end
>
> WDYT?
This seems kind of funky. If an AR object can be saved then it's
going to be valid anyway. In other words
my_object.valid? # false
my_object.save # true
my_object.valid? # true
is a super weird sequence. What context is this in?
At first glance (i.e. with no context) I don't think that's a good use
for mocks. You're introducing behavior and state into the mock ("when
save is called, change my valid state to true") which is getting a bit
clever and mixing concerns imo. The mocks created via the framework
should be pretty stupid and just respond how you want them to. If you
do need some actual behavior then I suggest you code up another object
that behaves as you need.
However as I said that's just a strange sequence anyway, which
suggests that maybe your design is a bit off.
Pat
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
