[rspec-devel] New Stub API Implemented

Brian Takita brian.takita at gmail.com
Thu Sep 28 23:53:56 EDT 2006


>
> Brian, if you want to take a look at the class level mocking please
>
feel free.It strikes me that there's probably already some duplication
> between the mock and stub implementations, so perhaps a single
> framework w/ both facilities is the way to go.
>

Yes, I think they can be integrated, particularly with the partial mocking
objects.
I'm thinking about adding the should_receive method to Object.

On 9/28/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 9/28/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Whoops, I didn't read the rspec stubbing thread. I did commit to the
> stub
> > branch though.
> > At least my changes also include some refactorings that clean up the
> > implementation.
>
> I think we should keep the stub facility in addition to the class
> level mocking I'm interested in.
> For me, stubbing is useful for that 'other' class the class under spec
> is using and won't run without, but not for dealing w/ values that are
> important to the spec itself. For example, if an ATM won't respond to
> messages you send it without a Display or a Dispenser, I'd stub out
> the Dispay for the specs that deal w/ how the ATM interacts w/ the
> Dispenser, but I'd MOCK the Dispenser itself. And vice versa.
>
> That said, I already use the existing mock framework for stubs and
> name them accordingly.
>
> mock_dispenser = mock("dispenser")
> mock_dispenser.should_receive(:etc, etc, etc)
> stub_display = mock("display")
> mock_dispenser.should_receive(:etc, etc, etc)
>
> Being able to do this instead:
>
> mock_dispenser = mock("dispenser")
> mock_dispenser.should_receive(:etc, etc, etc)
> stub_display = Object.new
> mock_dispenser.stub!(:etc, etc, etc)
>
> ... makes the spec much more clear.
>
> Brian, if you want to take a look at the class level mocking please
> feel free.It strikes me that there's probably already some duplication
> between the mock and stub implementations, so perhaps a single
> framework w/ both facilities is the way to go. Just let me know if you
> plan to, in which case I'll coordinate w/ you before I take any stabs
> at it.
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060928/9ac21326/attachment.html 


More information about the rspec-devel mailing list