-
Notifications
You must be signed in to change notification settings - Fork 25
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
Move tag list tests to proper browsers interactions #3791
Conversation
Thanks for the PR! 🎉 We've deployed an automatic preview for this PR - you can see your changes here:
|
const button = elem.shadowRoot.querySelector('d2l-button-subtle.d2l-tag-list-clear-button'); | ||
|
||
setTimeout(() => button.click()); | ||
clickElem(button); |
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 think we still want to do this kind of thing in a timeout in case the event gets fired synchronously from the click handler.
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 wasn't getting any flake locally without it, and I think it might always be safe to do this without, but it'd be good to know definitively either way before we convert/write more of these. I'll look into it.
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.
Also, if it's not safe, maybe we wrap them so it is always safe?
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.
Yeah maybe it makes sense for us to put the setTimeout
inside all of these utilities eh? The Promises they return can still resolve after the action has complete if that's what they're going for, but if you don't care you can just call it and then await
an event on the next line.
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.
Looked into this and discussed offline. There are multiple steps in other processes that make these interactions inherently significantly delayed (in the event loop, not actually time) so for now we're thinking these should be safe to run in this order without intervention, but we can always build in a delay later if needed.
🎉 This PR is included in version 2.132.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Uses proper browser mouse/keyboard interactions from the testing library instead of javascript methods/events to simulate them.