[rspec-devel] confusion with rspec mocks

[David Chelimsky]

On 8/15/07, Dan North <dan at tastapod.com> wrote:
>
>  David Chelimsky wrote:
>  On 8/15/07, Dan North <dan at tastapod.com> wrote:
>
>  Hi folks.
>
> I'm nearly there with the initial cut of Spec::Story. I have one example
> failing with an odd error from the rspec mock framework.
>
> I moved #with from MessageExpectation into BaseExpectation so I could
> stub!(:something).with(args).
>
>  That was a deliberate design choice - I don't believe stubs should
> care about args - if you care about args, then you want should_receive
> (because it's an expectation).
>
>  It's useful for when I want to say I care about the mock receiving
> eat("cheese") and I'm aware that it will also receive eat("pickle") but I
> don't care (i.e. that's not the intent of the example). But I want the
> example to fail if suddenly the object starts to eat("wood") because I might
> need to think about how it affects the behaviour.
>
>  I suppose you could just stub!(:eat) and then
> should_receive(:eat).with("cheese"), but sometimes I want
> to be more explicit than that.
>
>  Also, the #with method doesn't feel right alongside all the counter methods
> (once, twice, never, etc). I guess I've become used to having matchable args
> on stubs because jmock and mocha both support this.
>
>  In both cases it seems the args checking is being lost somewhere.
>
>  I can't explain this off-hand, but if you move :with back, does it
> work w/ should_receive?
>
>  No, it wasn't working with stub!(:add_listener), which is when I discovered
> that I couldn't filter on the args in the stub and I moved the with()
> method.
>
>  I just reverted the #with change to revive the original error and got this:
>
> Mock 'story runner' expected :add_listener with (no args) once, but received
> it 0 times
>  ./spec/spec/story/runner_spec.rb:57:
>
>  (I checked in the reverted version.)
>
>  Thanks for getting back so quickly, David.

I've fixed the problem that was causing that spec to fail - it had
nothing to do w/ the mocks, though there is obviously a failure in
feedback they are producing which I will look into.

But they were actually failing correctly because another part of the
spec was not doing what it appeared to be doing.

This is now resolved, with the import-rbehave branch passing the
pre_commit tasks with 100% coverage, etc, etc, etc. We'll be merging
this into trunk soon.

>
>  Cheers,
>  Dan
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>