-
Notifications
You must be signed in to change notification settings - Fork 353
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
Fix race conditions and clean up code in regression tests #837
Conversation
264494f
to
f03f500
Compare
@tatermelon, @jessebeach, @sh0ji, are one of you available fore review? |
@spectranaut the code changes just look like cleanup. Are there any behavior changes to review? |
@jessebeach yup just clean up! No behavior changes. |
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.
Cool. As soon as the tests pass, you're good to go.
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 see a lot of style fixes, which are great. I see no reason not to merge this.
Sorry if this was discussed elsewhere and I missed it, but what was the race condition issue? It's not immediately apparent here.
const waitAndCheckFocus = async function (t, selector, index) { | ||
return t.context.session.wait(async function () { | ||
return t.context.session.executeScript(function () { | ||
const [selector, index] = arguments; |
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.
Are selector
and index
being changed by the inner functions? They're already declared in the upper scope (waitAndCheckFocus
).
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.
hey @sh0ji this is actually a function that will be converted to a string then sent to the browser -- you can read about it here (ctrl-f executeScript): http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index_exports_WebDriver.html
It's not executed in the context of this script and arguments can only be provided via the argument object.
selector = arguments[0]; | ||
return document.activeElement === document.querySelector(selector); | ||
}, selector); | ||
}, 200); |
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.
Is there a reason this timeout is 200ms while the others are 500ms?
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 put the 200ms waits before I stress tests but found 500 was better -- I'll switch them all to 500 for consistency, thanks for th catch!
hey @jessebeach the current failures are expected -- they surface errors in the tests themselves (see comment #837 (comment)) |
Hmmm now I have new failures I really don't understand -- something with the test set up: https://travis-ci.org/w3c/aria-practices/builds/417355896?utm_source=github_status&utm_medium=notification |
Maybe something to do with async/await functions? |
42da138
to
549303b
Compare
549303b
to
efabcd3
Compare
@jessebeach -- this PR has some code and logic clean up, a couple race condition fixes (in my test code), and some lint error fixing. I'd like it to be accepted into the bocoup branch so I can work on top of these fixes. The errors in the CI are inconsistent and something I'd like to debug separately -- they are errors in the test infrastructure/coming from geckodriver. I'll have to enable logging and I'd like to do this on another PR. |
Test the CI