[Rspec-devel] define_instance_method, stub_with, and mock_with

David Chelimsky dchelimsky at gmail.com
Mon Sep 4 17:38:15 EDT 2006


On 9/4/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> David Astels wrote:
> > On 27-Aug-06, at 4:51 PM, David Chelimsky wrote:
> >> I also
> >> have yet to see a case where   using partial mocks is a better
> >> decision than improving the decoupling in the system under test.
> > I agree.  Partial mocks can get very confusing, very easily.
>
> OK, but what about partial stubs?  It's particularly handy to stub out
> Time.now, f'rinstance, so that all your expectations run at a particular
> "now", matching up with timestamps in fixtures, etc.  There's no way to
> do that via an API that requires you to create new instance objects for
> your mocks.  And I don't imagine you're suggesting that I decouple an
> app by asking for "time_handler" at startup...

There's a balance here. With something that's part of Ruby I tend to
think it preferable to use the class directly. Third party stuff
should get wrapped though, so you're not bound to it.

> Also, FWIW, it sounds like Mocha is likely to become included in (or at
> least used by) Rails core:
>
> http://rubyforge.org/pipermail/mocha-developer/2006-September/000017.html

Cool!

> I guess, depending on your viewpoint, that's either good for, bad for,
> or irrelevant to this discussion and rspec in general.

I think it is very relevant. I've been playing around w/ using Mocha
and Stubba from rspec. Haven't gotten it to work the way I want to
yet, but if we can tap into a solid mock framework that someone else
is maintaining, why not? The catch would be that the syntax for mocha
is slightly different - using "expects" instead of "should_receive".
But a simple search and replace should fix that - no? There are a
couple of others, like "returns" instead of "and_return", etc.

The other side of that is that
mock.should_receive(:msg).and_return(value) sounds a lot more like
subject.should_equal(value). Its more like the rest of rspec.

What is important to me is that whatever mock framework we use is
seamlessly integrated, auto-verified, etc. If mocha works its way into
rails, it will implicitly become somewhat of a standard. And while
rspec's expectation API and context/specify DSL offer something that
feels different from test/unit, the mock framework really doesn't
offer anything worthy of maintaining yet another framework.

Any other opinions?

David


More information about the Rspec-devel mailing list