-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[BUG] toHaveAttribute always passes when given a blank value string #16517
Comments
@radium-v Sounds legit to me, let me bring it up on the team meeting. |
@radium-v workaround: could you please try with empty slashes? 🤷♂️ await expect(element).toHaveAttribute('any-arbitrary-attribute', /.*/); Other than that, we discussed the feature and it sounds legit! We'll implement it |
I just tried these: await expect(element).toHaveAttribute("some-attr", /.*/);
await expect(element).toHaveAttribute("some-attr", /^$/); It seems the regex is comparing against empty string ( |
As workarounds, I wrote these extensions:
|
This patch changes `expect(locator).toHaveAttribute()` so that the `value` argument can be omitted. When done so, the method will assert attribute existance. Fixes microsoft#16517
Relates #16517. Revert "docs(python): add missing NotToHaveAttribute overloads (#17371)" This reverts commit 2e1ea29. Revert "docs(release-notes): add 1.26 release notes for language ports (#17345)" This reverts commit 4b8a85e. Revert "test: unflake "should support boolean attribute with options" (#17024)" This reverts commit 1dc05bd. Revert "fix: support toHaveAttribute(name, options) (#16941)" This reverts commit f30ac1d. Revert "feat: expect(locator).toHaveAttribute to assert attribute presence (#16767)" This reverts commit 622c73c.
Context:
Code Snippet
Describe the bug
The
toHaveAttribute
matcher doesn't work as expected with the checks above, sinceawait expect(element).toHaveAttribute("anything", "")
will always pass. Likewise,await expect(element).not.toHaveAttribute("anything", "")
will always fail for any attribute when used as a check for the presence of attributes. In our case, this primarily affects the use of boolean attributes likechecked
,disabled
,hidden
,open
, which are consideredtrue
when they're present, regardless of value.I think the
value
parameter fortoHaveAttribute
could be made optional, which would allow checking for the existence of attributes. The always-failingnot.toHaveAttribute
matcher would then be able to pass. This may also help to address #16270, though boolean attributes likely would need their own logic to match the allowed validity rules described in this MDN article.The text was updated successfully, but these errors were encountered: