Turn strict_predicate_matchers on by default #1277
Conversation
pirj
force-pushed
the
use-strict_predicate_matchers-by-default
branch
from
f2e3f62
to
884410f
Compare
pirj
force-pushed
the
use-strict_predicate_matchers-by-default
branch
from
98264cd
to
6423e9c
Compare
spec/spec_helper.rb
Outdated
| around do |example| | ||
| configuration = example.metadata[:with_configuration] | ||
| key = configuration.keys.first | ||
| value = configuration.values.first |
There was a problem hiding this comment.
I mean if you're going to extract this, you might as well detect / presume the hash and map on them...
There was a problem hiding this comment.
Sure, I've added to my todo to do that, and also to rework "with warn_about_potential_false_positives" and other shared examples that flip configuration bits.
Might even be extracted to Support if it's useful in other repos.
But I decided to leave this refactoring for later, to after 4.0.
There was a problem hiding this comment.
Please do it here first. Theres no point this being a hash and not used, if it doesn't later get refactored due to time constraints or other issues, this will be broken forever.
Alternatively just leave it as it was and save the whole refactoring for later.
There was a problem hiding this comment.
Theres no point this being a hash and not used
I tend to agree and started implementing it this way, but it looked quite clumsy (due to the lack of Hash#slice in Ruby 2.3).
Another approach could be to use two different metadata keys, with_configuration_key and with_configuration_value, quite clumsy too.
The value passed to with_configuration could be an array and using first/last. That imposes the question of how it should behave if we would be passing an array with more than two entries.
So, until this shared example gained some critical mass of usages of it, I decided not to grow its complexity.
There was a problem hiding this comment.
So, until this shared example gained some critical mass of usages of it, I decided not to grow its complexity.
It currently has unnecessary complexity for its use case in the form of the dynamic methods anyway, either simplify it so its specific to the config we're changing, or complete it please :)
There was a problem hiding this comment.
I can also rework existing usages of alternative approaches but would prefer to do this later, after #1253 is merged and after we remove include_chain_clauses_in_custom_matcher_descriptions et al to avoid unnecessary work.
spec/spec_helper.rb
Outdated
| around do |example| | ||
| configuration = example.metadata[:with_configuration] | ||
| key = configuration.keys.first | ||
| value = configuration.values.first |
There was a problem hiding this comment.
So, until this shared example gained some critical mass of usages of it, I decided not to grow its complexity.
It currently has unnecessary complexity for its use case in the form of the dynamic methods anyway, either simplify it so its specific to the config we're changing, or complete it please :)
|
cc @marcandre |
|
Great 🎉 |
…rspec/use-strict_predicate_matchers-by-default Turn strict_predicate_matchers on by default --- This commit was imported from rspec/rspec-expectations@1515f2b.
* Remove outdated option rspec/rspec-core@0407831 * Use the non-globally exposed RSpec syntax rspec/rspec-core#2803 * Use the non-globally exposed RSpec syntax, cont rspec/rspec-core#2803 * Comply to strict predicate matchers See: - rspec/rspec-expectations#1195 - rspec/rspec-expectations#1196 - rspec/rspec-expectations#1277
Related: #1196
Depends on: