-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Remove old predicates before redefining #2354
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
Conversation
9da5de4
to
165222b
Compare
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.
Leaving the implementation details up to you. Either works 👍
@@ -117,22 +118,27 @@ def rendering_views? | |||
# to the bug fix in rspec/rspec-core#2736, note some of these | |||
# predicates are a bit nonsensical, but they exist for backwards | |||
# compatibility, we can tidy these up in `rspec-rails` 5. | |||
undef :fixture_path? if respond_to?(:fixture_path?) |
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'm on the fence between this and
config.singleton_class.class_eval { attr_accessor :fixture_path }
# ...
def fixture_path?
!!fixture_path
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.
I'm not, I want to stick with add_setting
as much as possible, these work arounds will be removed in the next version major version of rspec-rails.
Remove old predicates before redefining
In an ideal world we'd not do this but because we are mixing into rspec-cores configuration this is preferable to inventing our own.