On 10/5/06, Brian Takita <brian.takita at gmail.com>
wrote:> I talked with David last night. We agreed to make the stub! method
quivalent
> to the expectation:
> obj.should_receive(:foobar).any_number_of_times
>
> So instead of:
> obj.stub!(:foobar).with(true)
>
> one would use:
> obj.stub!(:foobar).and_return(true)
>
> Does adding the stub! method to Mock sound good?
>
> class Mock
> def stub!(method_name)
> return should_receive(method_name).any_number_of_times
> end
> end
That''s more or less what I did. Basically there is a
MockInstanceMethods module with should_receive, should_not_receive and
stub!. This gets included in Mock and Object and becomes the entry
point for all mocking (complete, partial) and stubbing.
It''s committed to the trunk, so please check it out and have a look.
I''m pretty psyched about it.
David
>
> Thanks for leaving in the stub! method.
>
> Brian
>
>
> On 10/4/06, Brian Takita <brian.takita at gmail.com > wrote:
> >
> > > Also, stub! is a method of Object. If we where to replace it with
> partial mocking, we would have to move partial mocking to Object to replace
> this behaviour.
> >
> >
> > Unless things have changed, partial mocking is a feature of Module
> objects.
> >
> >
> >
> >
> > On 10/4/06, Brian Takita <brian.takita at gmail.com> wrote:
> > > I like the Object#stub! method because it''s syntax is
more focused and
> clearer than using a mock for the purpose of stubbing a method.
> > >
> > > obj.stub!(:foobar).with(true)
> > > vs.
> > >
> obj.should_receive(:foobar).and_return(true).any_number_of_times
> > >
> > > The stub method also communicates my intention to stub out the
method,
> just as mocking the method communicates my intention to verify that a
> certain message was passed to the object. I believe this makes my
> tests/specs clearer.
> > >
> > > Also, stub! is a method of Object. If we where to replace it with
> partial mocking, we would have to move partial mocking to Object to replace
> this behaviour.
> > >
> > >
> > >
> > > On 10/4/06, aslak hellesoy <aslak.hellesoy at gmail.com>
wrote:
> > > > On 10/4/06, David Chelimsky <dchelimsky at gmail.com>
wrote:
> > > > > Hey all -
> > > > >
> > > > > The trunk currently supports three types of
mocking/stubbing:
> > > > >
> > > > > Mock Objects (created dynamically at runtime)
> > > > > Partial Mocking of methods on existing classes
> > > > > Stubbing of methods on existing objects or classes
> > > > >
> > > > > The main difference between Partial Mocking and
Stubbing is that
> Stubs
> > > > > don''t verify.
> > > > >
> > > > > I''m wondering if we really need the stubbing
facility at all, given
> > > > > that we can do the same thing using Partial Mocks. If
we decided to
> > > > > yank the Stubs, we could add Partial Mocks support to
objects (right
> > > > > now it only works on classes).
> > > > >
> > > >
> > > > Sounds good to me.
> > > >
> > > > Just to be precise - one or more methods could be mocked on
an
> > > > individual *Object* (Class is an Object). So this would work
for any
> > > > Object, not just Class. Right?
> > > >
> > > > I don''t see a lot of value in stubbing without
verification if partial
> > > > mocking (or should we call it "object method
mocking" to be more
> > > > precise?) can be used on *any* object.
> > > >
> > > > > Note that this functionality is not part of a release
yet, so any
> such
> > > > > changes would only affect the brave trunk-dwellers
among you.
> > > > >
> > > > > Any thoughts on this? Can anyone explain to me why
stubs are useful
> in
> > > > > addition to partial mocks?
> > > > >
> > > >
> > > > I can''t think of a compelling reason.
> > > >
> > > > Cheers,
> > > > Aslak
> > > >
> > > > > David
> > > > > _______________________________________________
> > > > > Rspec-users mailing list
> > > > > Rspec-users at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > > >
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > >
> > >
> >
> >
>
>