A little unexpected behavior

[Robert Pankowecki (rupert)]

Is that a bug why those two examples: http://pastie.org/1529071 behave
differently?

If not, what's the reason for such behavior ?

Robert Pankowecki

[James Mead]

On 4 February 2011 18:52, Robert Pankowecki (rupert)

Hi Robert,

That's the behaviour I would expect. I've realised it's not made clear
in the documentation, but Mocha will match the most recently added
"stubs" or "expects" that has not yet been exhausted. In your second
example, the more recently added "stubs" matches all 3 invocations and
the "expects" is never reached. I think you should be able to reverse
the order i.e. with the "stubs" first and the "expects" second, to get
the behaviour you want. In this case, the "expects" will be the most
recently added and so will be checked first, and Mocha will fall back
to the "stubs" if the parameters don't match.

You can see some examples of this behaviour in the acceptance tests
e.g. MockedMethodDispatchTest [1]. I've added a Lighthouse ticket [2]
to improve the documentation to explain how it all works. I've also
added another ticket [3] to consider changing the order in which stubs
are matched - I think the trouble is that in some circumstances it's
more intuitive for it to work one way and in others more intuitive to
work the other.

I hope that all makes sense. Please feel free to add comments to the
Lighthouse tickets.

Regards, James.
----
http://jamesmead.org/

[1] https://github.com/floehopper/mocha/blob/master/test/acceptance/mocked_methods_dispatch_test.rb
[2] http://floehopper.lighthouseapp.com/projects/22289-mocha/tickets/82
[3] http://floehopper.lighthouseapp.com/projects/22289-mocha/tickets/83

[Robert Pankowecki]

Few conclusions that came to my mind after reading the tests:

a) obj.expects(...) <=> obj.expects(...).once

b) current behavior for me is totally counterintuitive. Could you
provide an example when it is more intuitive to behave one way and
when the other.

c) How I imagine it to work under the hood

1) Method is called
2) it should be checked against all expects(...).never definitions in
the order they were added
3) it should be checked against all other expectations in the order
they were added until first matching is found
4) it should be checked against all stubs in the order they were added
until first matching is found.

I won't insist on the fact the expectations should be checked before
stubs since that might be only my personal preference and it can be
easily achieved by me by writing them in the this order. However, I do
think that all expects(...).never should be verified at the beginning

Anyway, thanks for clarification the current behavior that everything
is checked in reverse order. It means that to have it working the way
I want I must write it like:

errors.stubs(:add).with(any_parameters)
errors.expects(:add).with(:name, :blank, anything)
errors.expects(:add).with(:name, Not( equals(:blank) , anything).never

This would mean: add ONLY :blank error on :name field and as many
errors as you want on other fields. Am i right?

Robert Pankowecki