-
Notifications
You must be signed in to change notification settings - Fork 57
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
Raise an error if the last arg is the wrong format #96
Conversation
I always accidentally write this: ```ruby assert_select "title", "Welcome", count: 1 ``` When I mean to write this: ```ruby assert_select "title", text: "Welcome", count: 1 ``` The first assertion is incorrect; it's looking for the string "Welcome", then using `{ count: 1}` as the assertion failure message if it's not found. Since the assertion failure message probably should not be a hash, I propose we raise an error if that argument is passed. This would make it easier to identify incorrectly written tests.
This test needs the second argument to be a hash, the third argument is intended for error message. This change is required for rails-dom-testing 2.1.0 which now raises an error if you have a misconfigured test (it was previously silent) [1]. [1]: rails/rails-dom-testing#96
This test needs the second argument to be a hash, the third argument is intended for error message. This change is required for rails-dom-testing 2.1.0 which now raises an error if you have a misconfigured test (it was previously silent) [1]. [1]: rails/rails-dom-testing#96
…ils/rails-dom-testing#96 most likely raised a new error How: Specifying text: fixed the error
* Bump tailwindcss-rails from 2.0.29 to 2.0.30 Bumps [tailwindcss-rails](https://github.com/rails/tailwindcss-rails) from 2.0.29 to 2.0.30. - [Release notes](https://github.com/rails/tailwindcss-rails/releases) - [Changelog](https://github.com/rails/tailwindcss-rails/blob/main/CHANGELOG.md) - [Commits](rails/tailwindcss-rails@v2.0.29...v2.0.30) --- updated-dependencies: - dependency-name: tailwindcss-rails dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> * What: tailwindcss-rails 2.0.30 brought a dom testing gem. This gem rails/rails-dom-testing#96 most likely raised a new error How: Specifying text: fixed the error * rubocop fixes --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: jcowhigjr <jcowhigjr+dev@gmail.com> Co-authored-by: John Cowhig <1895349+jcowhigjr@users.noreply.github.com>
I'm sorry I missed this change. I've written many assert_select statements as described in the problem above as such:
This has always seemed to work as my tests fail when the expected count of the elements is incorrect. The implementation seems inconsistent as a test such as this one will fail if there is only one such input element on the page:
By setting the count to 1 or eliminating the count check altogether, the test passes. If I go back and add the text: key, the test fails:
|
@ccasabona the inconsistency is intentional. If you use the Only this works as a shorthand: assert_select "title", "Welcome" But anything more complex and it's better to be explicit about what arguments you are using. In terms of your example, I don't think you need to make any changes: def test_assert_select_with_question_mark
render_html "<html><head><title>Welcome</title></head><body><input type=text value='hi' /></body></html>"
assert_select 'input[value=?]', 'hi' # pass
assert_select 'input[value=?]', 'hi', count: 1 # pass
assert_select 'input[value=?]', 'hello' # fails correctly: Expected at least 1 element matching "input[value=\"hello\"]", found 0.
assert_select 'input[value=?]', 'hello', count: 0 # pass
assert_select 'input[value=?]', text: 'hi' # Nokogiri::CSS::SyntaxError: unexpected '?' after 'equal'
assert_select 'input[value=?]', text: 'hi', count: 1 # Nokogiri::CSS::SyntaxError: unexpected '?' after 'equal'
end Using |
Thanks for making it clear about the distinction of inner text. |
I always accidentally write this:
When I mean to write this:
The first assertion is incorrect; it's looking for the string "Welcome", then using
{ count: 1 }
as the assertion failure message if it's not found. So for example, if you change the text tocount: 2
orcount: 0
your test could behave wrong.Since the assertion failure message probably should not be a hash, I propose we raise an error if that argument is passed. This would make it easier to identify incorrectly written tests.