-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Remove old predicates before redefining #2354
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.