-
-
Notifications
You must be signed in to change notification settings - Fork 397
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
Scrape out monkey patching #1245
Conversation
d22a6f9
to
fbd4401
Compare
fbd4401
to
133e5a8
Compare
eb8c832
to
1071be7
Compare
056c92f
to
1071be7
Compare
61c0bfc
to
8f3c3da
Compare
4504b25
to
8f3c3da
Compare
3daf73c
to
73c60f5
Compare
b330730
to
2926bc9
Compare
I suggest following our practice:
|
2926bc9
to
bbaef45
Compare
Green 💚 |
Filed minitest/minitest#861 |
I've already re-worked our build around it, its just the PR isn't merged yet |
Me too minitest/minitest#862 😄 |
bbaef45
to
6996e4f
Compare
Anything left to be done here? |
it "accepts and interacts with a matcher" do | ||
expect(@matcher).to receive(:matches?).with(@target).and_return(true) | ||
expect(@target).to @matcher | ||
end | ||
|
||
it "asks for a failure_message when matches? returns false" do | ||
expect(@matcher).to receive(:matches?).with(@target).and_return(false) | ||
expect(@matcher).to receive(:failure_message).and_return("the failure message") | ||
expect { | ||
expect(@target).to @matcher | ||
}.to fail_with("the failure message") | ||
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.
Did you find duplicates of these? I thought you were moving them (if so a comment saying "these are duplicates of file:line" etc is helpful when reviewing).
it "accepts and interacts with a matcher" do | ||
expect(@matcher).to receive(:matches?).with(@target).and_return(true) | ||
expect(@target).to @matcher | ||
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.
This is covered by more specific specs:
expect(RSpec::Expectations::PositiveExpectationHandler.handle_matcher(actual, matcher)).to eq :this_value it "overrides the failure message for positive expectations" do
it "asks for a failure_message when matches? returns false" do | ||
expect(@matcher).to receive(:matches?).with(@target).and_return(false) | ||
expect(@matcher).to receive(:failure_message).and_return("the failure message") | ||
expect { | ||
expect(@target).to @matcher | ||
}.to fail_with("the failure message") | ||
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.
Covered in:
expect(::RSpec::Expectations).to receive(:fail_with).with("message", 1, 2) it "overrides the failure message for positive expectations" do
}.to fail_with("the failure message") | ||
end | ||
|
||
context "on interpretters that have BasicObject" do |
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.
We do not support such interpreters.
it 'does not break the deprecation check on BasicObject-subclassed proxy objects' do | ||
begin | ||
should_enabled = RSpec::Expectations::Syntax.should_enabled? | ||
RSpec::Expectations::Syntax.enable_should unless should_enabled | ||
proxy_class.new(BasicObject.new).should be_proxied | ||
ensure | ||
RSpec::Expectations::Syntax.disable_should if should_enabled | ||
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.
We are dropping support for monkey-patching should
.
it "accepts and interacts with a matcher" do | ||
expect(@matcher).to receive(:matches?).with(@target).and_return(false) | ||
allow(@matcher).to receive(:failure_message_when_negated) | ||
|
||
expect(@target).not_to @matcher | ||
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.
Covered in:
expect(matcher.failure_message_when_negated).to eq "expected 77 not to to be composed of 7 and 11" matcher = double("matcher", :failure_message_when_negated => "Error!")
it "asks for a failure_message_when_negated when matches? returns true" do | ||
expect(@matcher).to receive(:matches?).with(@target).and_return(true) | ||
expect(@matcher).to receive(:failure_message_when_negated).and_return("the failure message for should not") | ||
expect { | ||
expect(@target).not_to @matcher | ||
}.to fail_with("the failure message for should not") | ||
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.
Covered in:
it "raises an expectation failure when `matches?` returns true" do
References to duplicated examples for a removed spec added
d983376
to
1ab4671
Compare
http://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero_monkey_patching_mode > we do want to encourage people to switch to the new syntax, so we plan to make RSpec 3 print a warning on first usage of any the old syntax methods (should, should_not, should_receive, etc) unless the should syntax has been explicitly enabled. This should nudge folks towards the new syntax while keeping RSpec friendly to new users and will pave the way for the old syntax to be disabled by default in RSpec 4. > zero-monkey-patching mode for RSpec... We plan for these config options to become the defaults in RSpec 4.0, so that RSpec 4.0 will have zero monkey patching out of the box. As for "disabled by default" vs "completely removed" and "default, out of the box" vs "impossible" I can only say that RSpec 4 was probably planned to be released earlier, as: > we'll probably be dropping support for 1.8.7 in RSpec 4 but we've also dropped 1.9, 2.0, 2.1 and 2.2 rspec/rspec-core#2301 (comment) > In RSpec 4, we plan to extract all monkey patching from RSpec and move it into a separate gem, so that monkey patching is opt-in instead of opt-out and users have to explicitly install and load a gem to get it. `rspec-should` (or `rspec-monkey` as it's also about exposing example group DSL in the top-level/Module?) will be released later. Those using the monkey-patched `should` syntax are not encouraged to update to RSpec 4 until this gem is extracted. Those using the globally-exposed DSL are encouraged to use `RSpec.describe`/`RSpec.shared_examples_for` instead.
1ab4671
to
e8e8bfc
Compare
This commit was imported from rspec/rspec-expectations@566311c.
…rspec/remove-monkey-patching Scrape out monkey patching --- This commit was imported from rspec/rspec-expectations@ebab7e2.
Sibling PRs:
Prerequisite PRs:
Stop using globally exposed DSL rspec-rails#2420
Use globally unexposed DSL rspec-support#457
Add a check to support both RSpec 3 & 4 rspec-rails#2425
Remove temporary commit. CI is expected to fail on Core/Mocks/Support/Rails steps, as
disable_monkey_patching!
calls methods that were removed with no replacement. I'll use themaintenance-branch
temporary commit hack to fraternize those sibling PRs.http://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero_monkey_patching_mode
As for "disabled by default" vs "completely removed" and "default, out of the box" vs "impossible" I can only say that RSpec 4 was probably planned to be released earlier, as:
but we've also dropped 1.9, 2.0, 2.1 and 2.2
rspec/rspec-core#2301 (comment)
rspec-should
(orrspec-monkey
as it's also about exposing example group DSL in the top-level/Module?) will be released later.Those using the monkey-patched
should
syntax are not encouraged to update to RSpec 4 until this gem is extracted.Those using the globally-exposed DSL are encouraged to use
RSpec.describe
/RSpec.shared_examples_for
instead.