-
-
Notifications
You must be signed in to change notification settings - Fork 753
Prevent should from circumventing target check #2800
Conversation
lib/rspec/core/memoized_helpers.rb
Outdated
@@ -78,7 +78,7 @@ def subject | |||
# @note If you are using RSpec's newer expect-based syntax you may | |||
# want to use `is_expected.to` instead of `should`. | |||
def should(matcher=nil, message=nil) | |||
RSpec::Expectations::PositiveExpectationHandler.handle_matcher(subject, matcher, message) | |||
is_expected.to(matcher, message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think the reason why this was the way it was, is because expect
can be disabled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems to be yet another reason. should
/should_not
support OperatorMatcher
, while is_expected.to
does not, due to its prevent_operator_matchers
check.
Not sure about the reasoning behind this, probably it does not read right, e.g. it is expected to > 0
. Obviously, it is expected to be > 0
sounds better.
However, it should > 0
isn't easy on the ear either.
I intend to assume that should
always represents the value expectation syntax, and:
- revert the current change to
is_expected.to
- add an explicit call to
enforce_value_expectation
similar to what we do inValueExpectationTarget
.
This will print a warning for:
subject(:action) { -> { raise } }
it { should raise_error StandardError }
but the following will continue working:
it { should > 3 }
@JonRowe @benoittgt Is this a correct approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also love to move should
/should_not
/is_expected
to rspec-expectations
in a follow-up. Can you think of some implications to that? All of them imply that:
This only works if you are using rspec-expectations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be now is a good moment to:
- deprecate
should
withOperatorMatcher
- retire
OperatorMatcher
since BeComparedTo
does this job anyway with better readability.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With should being removed there is no need to deprecate a specific matcher with it.
64b7ad3
to
13ebc90
Compare
Update: I've used a different approach - checking for a value matching support of matchers passed to |
11091a1
to
2403584
Compare
I give up on Travis. |
This redundant as the whole |
Reopened because we still need to deprecate this for |
@JonRowe ok to merge this? |
lib/rspec/core/memoized_helpers.rb
Outdated
matcher_supports_value_expectations = begin | ||
matcher.supports_value_expectations? | ||
rescue | ||
true | ||
end | ||
return if matcher_supports_value_expectations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just looks ugly 😂 , WDYT about extracting the block to a method e.g:
matcher_supports_value_expectations = begin | |
matcher.supports_value_expectations? | |
rescue | |
true | |
end | |
return if matcher_supports_value_expectations | |
return if matcher_supports_value_expectations? |
and elsewhere:
# @private
def matcher_supports_value_expectations?
matcher.supports_value_expectations?
rescue
true
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No objections. Especially since enforce_value_expectation
will remain only in RSpec 3.x, and will be removed along with should
in 4.
Fixed.
eebc91e
to
9886b8c
Compare
By directly instantiating expectation handler, should/should_not was circumventing enforce_value_expectation check. subject(:action) { -> { raise } } it { should raise_error StandardError } would not print "The implicit block expectation syntax is deprecated", while subject(:action) { -> { raise } } it { is_expected.to raise_error StandardError } will. See rspec/rspec-expectations#1139
d7c9001
to
d04af61
Compare
…-should-oneliners Prevent should from circumventing target check --- This commit was imported from rspec/rspec-core@e95cfe3.
By directly instantiating expectation handler, should/should_not was circumventing enforce_value_expectation check.
would not print "The implicit block expectation syntax is deprecated", while
will.
See rspec/rspec-expectations#1139