-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error on expects.with
with empty hash argument
#657
Comments
workaround is to use block matcher |
@floehopper just in case module ParameterMatchers
# @private
class PositionalOrKeywordHash < Base
def matches?(available_parameters)
parameter, is_last_parameter = extract_parameter(available_parameters)
# return false unless HasEntries.new(@value).matches?([parameter]) <---- commenting this line makes the tests pass Possibly you need that for something else, but I'd love to get that fixed |
@josesei Thanks for reporting this. I had independently come to the same conclusion as you as to where the problem lies. I've managed to write a couple of failing unit tests in #660 which reproduce the issue. That line of code is needed to handle nested matchers with keyword arguments (see test below), but clearly the implentation isn't quite right. My head is pretty scrambled right now, but I'll try to get it fixed as soon as I can. mocha/test/unit/parameter_matchers/positional_or_keyword_hash_test.rb Lines 38 to 41 in e62fa61
|
sounds good, thx! |
@josesei Actually - ignore that! |
@josesei I've got some tidying up to do and some double-checking I haven't broken anything else, but I think the changes in the |
yep, it does work now! appreciate the effort! it worked for me for ruby 2.6 and rails 5, mocha version I guess it has to do with the keyword params compat thingy, but I'm sure you have it |
In this commit [1] which fixed #647 and which was released in v2.3.0, a top-level `Hash` argument passed into `Expectation#with` was implicitly converted into a `HasEntries` matcher in order to handle "nested" matchers used within the keys & values of the `Hash`. This _new_ behaviour makes particular sense for keyword arguments where the requirement to wrap such a `Hash` in a call to `#has_entries` was a bit surprising as described in #647. However, that change inadvertently broke basic `Hash` parameter matching as described in #657, because the `HasEntries` matcher only needs to match each of the entries specified; it will still match if there are *extra* entries in the `Hash` it is matching against. In order to fix this without breaking the "nested" matching behaviour added in [1], I've added an optional `exact` keyword argument to the `HasEntries` constructor and set this to `true` when it's called from `PositionalOrKeywordHash#matches?`. I haven't bothered to document the new `exact` argument, because currently it's only used internally. I did consider introducing a new matcher more like `RSpec::Matchers#match` matcher [2], but I decided that wouldn't provide as elegant a solution to #647 as the change in this commit. I can imagine introducing something like `#has_exact_entries` to the public API, but it would probably make sense to add something similar for exact matching of array items at the same time, so I'm going to leave that for now. I've added a few acceptance tests in this commit which would have caught the problem that I inadvertently introduced in [1] and a few that cover the "nested" matching behaviour that was introduced in that commit (previously I had only added a unit test). [1]: f94e250 [2]: https://www.rubydoc.info/github/rspec/rspec-expectations/RSpec/Matchers#match-instance_method
@josesei Thanks for testing. The problem was something I accidentally introduced in v2.3.0 (specifically f94e250) as a fix for #647 where a |
Makes sense, thanks for the insights and all your work! |
This fix has been released in v2.4.3. |
How to reproduce:
minitest (5.24.1)
mocha (2.4.2)
rails (6.1.7.8)
Ruby 3.3.0
Failure:
Minitest::Assertion: unexpected invocation: MyKlass.method_accepting_hash({})
unsatisfied expectations:
test/support/mocha_error_test.rb:31:in `block in class:MochaErrorTest'
The text was updated successfully, but these errors were encountered: