-
-
Notifications
You must be signed in to change notification settings - Fork 763
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
disable_monkey_patching not preventing global alteration of describe #2301
Comments
Some more relevant code for what minitest/spec is doing can be found here: |
Yep, for backwards compatibility reasons we were forced to do it this way. Historically, calling 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. That should solve the issue for you but as a breaking change we can't do it until RSpec 4 given our commitment to SemVer. In the meantime, is there any reason you are loading both rspec-core and minitest in the same process? IMO, it doesn't make sense to load both. If you are using both, I'd expect you to run them as separate processes and not be both loaded in the same process at the same time. If you're using |
Thank you so much. I totally forgot that I can just set But yea, I'm totally willing to put some time into a PR for this that's targetted at being merged into RSpec 4. |
We haven't started on RSpec 4 yet and have no plans to start in the near future, so such a PR would likely just sit stagnant and create extra work to resolve the merge conflicts in the future when we do start on RSpec 4. |
This reverts commit 994cb7a. The original fix was never shown to have fixed anything, and looks to have triggered #1645 and rspec/rspec-core#2301. Fixes #1645.
This reverts commit 994cb7a. The original fix was never shown to have fixed anything, and looks to have triggered #1645 and rspec/rspec-core#2301. Fixes #1645.
This reverts commit 994cb7a. The original fix was never shown to have fixed anything, and looks to have triggered #1645 and rspec/rspec-core#2301. Fixes #1645.
This reverts commit 994cb7a. The original fix was never shown to have fixed anything, and looks to have triggered rspec#1645 and rspec/rspec-core#2301. Fixes rspec#1645.
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.
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.
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.
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.
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.
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.
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 #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.
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 #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.
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.
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.
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.
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.
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 #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.
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.
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.
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 #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.
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.
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 #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.
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 #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.
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 #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.
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.
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 #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.
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.
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.
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.
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. --- This commit was imported from rspec/rspec-mocks@930b8cc.
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. --- This commit was imported from rspec/rspec-core@66850ee.
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. --- This commit was imported from rspec/rspec-expectations@c033456.
I'm using Minitest 5.8.4 for some of my older tests. This includes
minitest/spec
that gives me rspec-likedescribe
in my tests.When bundle the gem
rspec-rails
3.5.1 (which of course brings inrspec-core
3.5.1) all of thedescribe
code in my minitests no longer work, and I get the error ofundefined local variable or method 'describe' for MyTest:Class
(where this is a subclass ofActionController::TestCase
)To attempt to remedy this, I've tried to disable RSpec's monkey patching, but this isn't seeming to work either.
I believe (although I'm missing a few things), that this is because when you disable_monkey_patching, it isn't preventing it, but rather attempting to undo the prior changes. Related bits of code from rspec-core below:
I think the change that needs to happen, is to prevent
describe
from ever attaching to top level binding to begin with, and not overriding it if it might have been defined elsewhere. Help/thoughts?The text was updated successfully, but these errors were encountered: