Simplify parameter matcher for hashes #739
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I ran the following command:
bundle exec rubocop --auto-gen-config
i.e. * `once` is equivalent to `times(1)` * `twice` is equivalent to `times(2)` * `at_least_once` is equivalent to `at_least(1)` * `at_most_once` is equivalent to `at_most(1)`
Make it clearer that `Expectation#times` can be called with either a number or a range.
…for-cardinality-related-methods Improvements to docs for cardinality related methods
Modifies expectation so that the expected method must be called exactly
three times. While the word "thrice" is somewhat archaic english,
there's no harm in providing it for those that want to use it.
Note that we've also had to re-generate the rubocop TODO list mainly to
cope with the longer length of the `Expectation` class definition using
the following command:
bundle exec rubocop --auto-gen-config
Add `Expectation#thrice`
This version has been EOL since 31 Mar 2017 [1], which is almost 8 years ago. `Mocha::Configuration#stubbing_method_on_nil` and `StubbingNilTest` are now moot, because as of Ruby v2.2 `nil` is frozen. The behaviour tested in the latter is already tested in the more generic `StubbingFrozenObjectTest`. See this commit [2] for details. Closes freerange#628. [1]: https://www.ruby-lang.org/en/downloads/branches/ [2]: freerange@a65ea1e
…-v2.1 Drop support for Ruby v2.1
This brings the gemspec description more into line with that in the README. Note that the gemspec description is used on rubygems.org [1]. Closes freerange#692. [1]: https://rubygems.org/gems/mocha
…ption Improve gemspec description
I was seeing the following warning when I run bundle exec rake lint
locally with Ruby v3.3.6:
~/.asdf/installs/ruby/3.3.6/lib/ruby/gems/3.3.0/gems/rubocop-0.58.2/lib/rubocop.rb:607:
warning: base64 was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.4.0.
You can add base64 to your Gemfile or gemspec to silence this warning.
I imagine newer versions of rubocop might include this as an explicit
dependency or maybe it has become unnecessary, but this fixes the
immediate problem for me.
Closes freerange#703.
The base64 gem does not support Ruby v2.2 and so the previous commit [1] was causing a CI build failure [2]. [1]: freerange@8c49314 [2]: https://app.circleci.com/pipelines/github/freerange/mocha/695/workflows/4c622995-5468-4cfc-a3cf-405fecb39cb0/jobs/10161
In preparation for the Ruby v3.4 release.
I was seeing the following warning when I ran `bundle exec rake lint`
locally with Ruby v3.4.0-rc1:
~/.asdf/installs/ruby/3.4.0-rc1/lib/ruby/gems/3.4.0+1/gems/rubocop-0.58.2/lib/rubocop.rb:607:
warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add ostruct to your Gemfile or gemspec to silence this warning.
Ruby v3.4 was released earlier today [1]. [1]: https://www.ruby-lang.org/en/news/2024/12/25/ruby-3-4-0-released/
…d-matrix Add Ruby v3.4 to CI build matrix
I was seeing the following warnings with Ruby v3.4:
test/method_definer.rb:3: warning: redefining 'object_id' may cause serious problems
test/method_definer.rb:3: warning: redefining '__id__' may cause serious problems
* Assert the string representation of the object instead of just the
pattern.
* Actually check `Object#id` is not called as implied by the test name.
* Ignore the Ruby warning when `Object#object_id` is redefined.
Closes freerange#709.
Fix Ruby v3.4 warnings in ObjectInspectTest
Most of the complication in the default `Gemfile` was to do with rubocop dependencies/compatibility. Extracting this separate `gemfiles/Gemfile.rubocop` simplifies the default `Gemfile` at the cost of making it slightly more complicated to run the `lint` rake task.
This is what I've been using locally for some time without any problems.
* This means we can considerably simplify `gemfiles/Gemfile.rubocop`, because we no longer need any of the workarounds. * I've regenerated the `.rubocop_todo.yml` file. * `Metrics/LineLength` has moved to `Layout/LineLength`. * The equivalent of the `IgnoredPatterns` attribute in `Metrics/LineLength` for `Layout/LineLength` is `AllowedPatterns`. * I have not *yet* opted in to a bunch of *new* cops, so the output is quite verbose. * Similarly, I haven't *yet* opted in to new cops by default by enabling the `AllCops/NewCops` config option. * There is a tip suggesting the `rubocop-rake` extension might be useful which I plan to address separately.
And re-generate to-do list.
I had to change the line numbers of a couple of assertions to match the new line numbers after the blank lines were added.
…arnings Builds fail fast on any ruby warnings
the previous test asserted _should_match_ and the test deleted here asserted _should_not_match_. The reason it did not match is because the entry did not match (due to an extra k3: 'v3'). It had nothing to do with keyword argument matching.
Expected keyword args will always be the last args anyway. So, if a positional hash matches keyword args but isn't the last one, the expectation will fail regardless as the remaining args won't have any matcher to match with.
The subclasses didn't seem to be pulling their weight anymore. A hook method where only one of the subclasses wants to customize the hook/do additional checks seems like a force-fitted design choice.
nitishr
force-pushed
the
simplify-parameter-matcher-for-hashes
branch
from
6ddc23b to
f17e5e0
Compare
floehopper
force-pushed
the
main
branch
2 times, most recently
from
ebb1c3e to
31e433a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improves the handling of keyword and positional hash argument matching. Simplifies the logic around matching keyword and positional hashes, removes redundant code, and ensures that the behavior aligns with Ruby's keyword argument handling.
Key Changes:
Simplified
to_matcherMethod:lastparameter from theto_matchermethod ininstance_methods.rb. This simplifies the logic and removes unnecessary complexity in determining whether a matcher is the last in a sequence.Refactored
PositionalOrKeywordHashClass:last_expected_valueparameter and related logic from thePositionalOrKeywordHashclass. The class now focuses on matching hash entries exactly and handling keyword arguments more straightforwardly.matches?method to handle both positional and keyword hashes without needing to check if the matcher is the last one.matches_last_actual_value?andlast_expected_value_is_positional_hash?.Updated Tests:
lastparameter, as it is no longer relevant.strict_keyword_argument_matching_test.rbto reflect the new behavior, ensuring that positional and keyword arguments are matched correctly.