You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 30, 2024. It is now read-only.
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.
0 commit comments