-
Notifications
You must be signed in to change notification settings - Fork 48
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 flakey tests #184
Merged
Merged
✅ Fix flakey tests #184
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes a frame may take longer than expected to load. Even the JS only frame may load after modifying the frame document causing that test to flake. On windows, frames can take even longer to load than 3s, so the wait timeout was upped to 5s and the hook timeout was removed.
It's possible for the test to continue after an asset has been accessed but before the request has been intercepted causing it to flake. Delaying when asset access is detected should help the request be intercepted in time for the assertion.
Sometimes it can take more than half of a second for the server to shutdown when forcefully terminating. Removing the arbitrary wait and making the test more deterministic should show if this was a test timing issue, or if termination itself is flakey.
wwilsman
force-pushed
the
ww/fix-flakes-attempt-1
branch
from
February 9, 2021 23:31
c1dc6f2
to
a1512bd
Compare
Robdel12
reviewed
Feb 10, 2021
await expect( | ||
fetch('http://localhost:5338/percy/healthcheck', { timeout: 10 }) | ||
).rejects.toThrow(); | ||
// check a few times rather than wait on a timeout to be deterministic |
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.
connnveerrrggeeeeee
Re-ran latest CI 4-5 times and it didn't fail. This looks good to go. inb4 it fails after merging |
Robdel12
approved these changes
Feb 10, 2021
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.
🏁 🐛 🔨
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is this?
Some tests are flakey. This PR aims to unflake them all
@percy/dom
frame serialization testsSometimes a frame may take longer than expected to load. Even the JS only frame may load after modifying the frame document causing that test to flake. On windows, frames can take even longer to load than 3s, so the wait timeout was upped to 5s and the hook timeout was removed.
@percy/core
capture handles closing during network idleExpected:
Network error: Page closed
Received:
Protocol error (Runtime.callFunctionOn): Page closed
Received message suggests that the page is sometimes closing either during the provided script execution or after the second network idle during DOM serialization script execution.
It's possible for the test to continue after an asset has been accessed but before the request has been intercepted causing it to flake. Delaying when asset access is detected should help the request be intercepted in time for the assertion.
@percy/cli-exec
start abort testThe test sends the process quit signal after running the
exec:start
command, then issues a request to see if the server is down. The server is sometimes still up when that request is sent, but it should be on its way down.Sometimes it can take more than half of a second for the server to shutdown when forcefully terminating. Removing the arbitrary wait and making the test more deterministic should show if this was a test timing issue, or if termination itself is flakey.
@percy/core
flakey coverageCoverage is sometimes missing from here. Not sure which test normally covers this, but a test was added that should always cover this as long as it passes.