Inconsistent return value of stubs() / expects()

[vlad-pisanov]

According to the docs, the result of stubs() and expects() is the "last-built expectation which can be further modified by methods on Expectation. This applies to both .stubs(:foo) and .stubs(foo: 1) invocations.

This seems to be true when stubbing methods on any class except Mock objects. For Mock objects, the return value is sometimes an Expectation, and sometimes a Hash.

# key-value stubbing returns the right thing on String ✔️
String.stubs(foo: 1, bar: 2)
#<Expectation:0x7f9e73aa6fe0 allowed any number of times, invoked never: String.bar(any_parameters) >

# key-value stubbing returns the wrong thing on Mock ❌
obj = stub()
obj.stubs(foo: 1, bar: 2)
# {:foo=>1, :bar=>2}

# key-stubbing returns the right thing on Mock ✔️
obj.stubs(:foo)
#<Expectation:0x7f9e73aa6fe0 allowed any number of times, invoked never: #<Mock:service>.foo(any_parameters) >

[floehopper]

@vlad-pisanov Thanks for opening this issue. You are correct that the behaviour does not match the documentation and that seems to have been the case since the feature was first introduced 13 years ago!! I think fixing it should be relatively straightforward, but I am slightly questioning whether the documented behaviour is actually sensible. Since I don't think the order of entries in a Hash is defined, it may not be obvious which is the "last" expectation that gets returned. I wonder if it might be less surprising to return an array of expectations...? Do you have any thoughts? Do you have a specific use case that would help guide me?

[vlad-pisanov]

@floehopper A list of expectations might be nice, but arguably overkill. I like how the docs say that:

object = mock()
object.stubs(:stubbed_method_one => :result_one, :stubbed_method_two => :result_two)

# is exactly equivalent to

object = mock()
object.stubs(:stubbed_method_one).returns(:result_one)
object.stubs(:stubbed_method_two).returns(:result_two)

If it's exactly equivalent, then the result would be the last Expectation defined. As of Ruby 1.9.1, Hash keys enumerate in the order they were inserted so it should be predictable.

My use case is actually simple, in our codebase, we use this shortcut quite a bit:

UserLogic.expects(age: 42).twice

^ if this syntax worked even with a single key on Mock objects, we'd be all set. 😄

[floehopper]

@vlad-pisanov

Thanks - it's helpful to have that context! What you say makes a lot of sense to me.

As of Ruby 1.9.1, Hash keys enumerate in the order they were inserted so it should be predictable.

I thought hash keys being ordered according to insertion order wasn't part of the Ruby "spec" and thus not guaranteed for all flavours of Ruby, but I might be out-of-date on that understanding. The most authoritative information I've been able to find after a quick internet search is this Stack Overflow answer, but that's very old and inconclusive. However, I note that the following spec is in the current Ruby repo, so maybe it's OK to rely on after all:

https://github.com/ruby/spec/blob/aaf998fb8c92c4e63ad423a2e7ca6e6921818c6e/core/hash/keys_spec.rb#L6-L14

[floehopper]

@vlad-pisanov I've just merged a fix (#525). Is there any chance you could try out the latest version in main, i.e. by using something like gem 'mocha', github: 'freerange/mocha' in your Gemfile, to see if it resolves your issue. If all is well I'll try to get a release out.

[vlad-pisanov]

@floehopper works like a charm! Thank you 🙏

[floehopper]

@vlad-pisanov Thanks for testing it. We'll try to get a release out as soon as we can.

[floehopper]

@vlad-pisanov This was released in v1.14.0.