-
Notifications
You must be signed in to change notification settings - Fork 59
Deprecate assert_select* in preparation for rename #91
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
This change is a companion PR to [rails/rails#41291][]. While it's possible that [rails/rails#41291][] may make Capybara assertion integration possible, there is still a possibility that applications would continue to use rails-dom-testing (or both!) to make assertions about HTML. Capybara also declares an `assert_select` method and while the method names collide, "select" in one case means CSS selector while "select" means `<select>` elements in the other. Since the tool itself includes `dom` in the package name, and includes `assert_dom_equal` helpers already, renaming `assert_select` and its other variations to methods starting with `assert_dom` unifies the interface. [rails/rails#41291]: rails/rails#41291
@@ -178,6 +178,7 @@ def assert_select(*args, &block) | |||
nest_selection(matches, &block) if block_given? && !matches.empty? | |||
end | |||
end | |||
deprecate assert_select: "assert_select will be renamed to assert_dom in an upcoming release" |
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.
Do we think that assert_css_select
or assert_dom_select
is a more communicative new name than assert_dom
?
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.
Don't think so, no.
Blam! |
Benefitting from that leftover Active Support deprecation require 😂 |
Bridge the gap between [rails#91][] (shipped) and [rails#92][] (open) by declaring [alias_method][] expressions for each `assert_select` variation, adding `assert_dom` variations to the interface. [rails#91]: rails#91 [rails#92]: rails#92 [alias_method]: https://docs.ruby-lang.org/en/3.0.0/Module.html#method-i-alias_method
On the heels of [rails/rails-dom-testing#91][] and [rails/rails-dom-testing#93][], and in preparation for [rails/rails-dom-testing#92][] [rails/rails-dom-testing#91]: rails/rails-dom-testing#91 [rails/rails-dom-testing#92]: rails/rails-dom-testing#92 [rails/rails-dom-testing#93]: rails/rails-dom-testing#93
Bridge the gap between [#91][] (shipped) and [#92][] (open) by declaring [alias_method][] expressions for each `assert_select` variation, adding `assert_dom` variations to the interface. [#91]: rails/rails-dom-testing#91 [#92]: rails/rails-dom-testing#92 [alias_method]: https://docs.ruby-lang.org/en/3.0.0/Module.html#method-i-alias_method
This change is a companion PR to rails/rails#41291. While it's
possible that rails/rails#41291 may make Capybara assertion
integration possible, there is still a possibility that applications
would continue to use rails-dom-testing (or both!) to make assertions
about HTML.
Capybara also declares an
assert_select
method and while the methodnames collide, "select" in one case means CSS selector while "select"
means
<select>
elements in the other.Since the tool itself includes
dom
in the package name, and includesassert_dom_equal
helpers already, renamingassert_select
and itsother variations to methods starting with
assert_dom
unifies theinterface.