Skip to content
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

Add 'hasAttribute' method to DomNodeState #1045

Closed
miherlosev opened this issue Dec 9, 2016 · 9 comments
Closed

Add 'hasAttribute' method to DomNodeState #1045

miherlosev opened this issue Dec 9, 2016 · 9 comments
Assignees
Labels
API MODIFICATION LEVEL: non-breaking changes STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: API TYPE: enhancement The accepted proposal for future implementation.
Milestone

Comments

@miherlosev
Copy link
Collaborator

No description provided.

@AlexanderMoskovkin
Copy link
Contributor

AlexanderMoskovkin commented Feb 15, 2017

We have getAttribute method, do we really need hasAttribute?

await t.expect(element.hasAttribute('attr')).ok()

can be easily replaced with

await t.expect(element.getAttribute('attr')).ok()

/cc @miherlosev @DevExpress/testcafe

@miherlosev
Copy link
Collaborator Author

It will not work then attribute value equals ''.
I saw this case in animations (class name value toggles from empty to a some value)

<div class="fade"></div>
...
<div class=""></div>

@AlexanderMoskovkin
Copy link
Contributor

why not

await t.expect(element.hasClass('fade')).ok()

?

@AlexanderMoskovkin
Copy link
Contributor

but possible you are right because it doesn't work for an element like

<div contenteditable />

@miherlosev
Copy link
Collaborator Author

miherlosev commented Feb 15, 2017

More

<input type="text" name="lname" disabled>

@AlexanderMoskovkin
Copy link
Contributor

ok, I'm agree)

@AlexanderMoskovkin AlexanderMoskovkin added this to the Planned features milestone Feb 15, 2017
@AlexanderMoskovkin AlexanderMoskovkin added TYPE: enhancement The accepted proposal for future implementation. and removed TYPE: proposal labels Feb 15, 2017
@inikulin
Copy link
Contributor

Just why not to compare with void 0?

@miherlosev
Copy link
Collaborator Author

Yes, we can check a returned value.
But, it's more redable to use hasAttribute

Example

<input type="text" name="lname" test="" disabled>

.expect(input.getAttribute('wrong')).eql(null)
.expect(input.getAttribute('disabled')).eql('') //attribute without value returns ''
.expect(input.getAttribute('test')).eql('')

versus

.expect(input.hasAttribute('wrong')).notOk()
.expect(input.hasAttribute('disabled')).ok()
.expect(input.hasAttribute('test')).ok()

@lock
Copy link

lock bot commented Mar 29, 2019

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.

@lock lock bot added the STATE: Auto-locked An issue has been automatically locked by the Lock bot. label Mar 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 29, 2019
kirovboris pushed a commit to kirovboris/testcafe-phoenix that referenced this issue Dec 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
API MODIFICATION LEVEL: non-breaking changes STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: API TYPE: enhancement The accepted proposal for future implementation.
Projects
None yet
Development

No branches or pull requests

3 participants