Expectations with String keys misidentified as keyword arguments

[seandilda]

I'm testing mocha 2.0.2 on ruby 3.1.3 and ran into an issue where a parameter matcher specifying a hash with String keys is being treated as keyword arguments by mocha.

Example code:

require 'mocha/api'

include Mocha::API
mocha_setup

class Example
  def foo(args); end
end

example = Example.new
example.expects(:foo).with('key' => 'value')
example.foo({ 'key' => 'value' })

This produces the following deprecation warning:

Mocha deprecation warning at mocha_test.rb:12:in `<main>': Expectation defined at mocha_test.rb:11:in `<main>' expected keyword arguments ("key" => "value"), but received positional hash ({"key" => "value"}). These will stop matching when strict keyword argument matching is enabled. See the documentation for Mocha::Configuration#strict_keyword_argument_matching=.

It looks like mocha treated .with('key' => 'value') as specifying a keyword argument instead of a Hash argument. Since keyword argument syntax looks like a hash with symbol keys, it should be safe to assume that any the parameter is intended to be a Hash if any of the keys aren't Symbols.

[floehopper]

@seandilda

Am I right in thinking this is just a special case of #593?

[seandilda]

@floehopper they are definitely related. I see #593 as an request for enhancement, as I believe the code is likely working as intended, but maybe not the way that would be most useful for users like myself.

I see this issue as a bug as an expectation that is unambiguously a Hash expectation is being misidentified as being a keyword expectation.

[floehopper]

@seandilda Thanks for explaining. While I think I see the distinction you are drawing from a user's point of view, in implementation terms I don't think there's going to be any meaningful difference between this and #593. I may have missed something, but if #593 is fixed then that should also fix this issue - is that correct?

[seandilda]

There are some slight differences in the issues, but it is possible a general fix for #593 will also fix this issue.

This issue is about how the expected parameters are parsed. #593 is about how the arguments used when calling the mock are parsed/compared to expected parameters.