-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[Automated Testing]: Fix preview e2e tests #35565
Conversation
Size Change: +271 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
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.
Good catch, Nik.
I ran tests locally using the following snippet ten times, and all of them were green 👍
for i in {1..10}; do npm run test-e2e -- packages/e2e-tests/specs/editor/various/preview.test.js; done
Locally tests were passing for me as well 😄 |
At this point, it's expected from e2e tests 😄 |
// A success notice should show up | ||
return page.waitForSelector( '.components-snackbar' ); | ||
// `PostPublishPanelPostpublish` will be visible after the post is published. | ||
return page.waitForSelector( '.post-publish-panel__postpublish' ); |
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.
Looks like this is not there in some cases. What if we dismiss the previous snackbar before checking again?
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.
Seems the alternative PR didn't seem to do the trick either.. How do you feel about adding a temp fix for this test for now to make CI green and handle the main problem separately?
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.
Sure, sounds good
Fixes: #35387
Previously
publishPost
util relied on waiting for the snackbar to exist, but after #34731 a snackbar is shown in other cases as well - like saving a draft. This can create unexpected results with race conditions. An example would be the preview test here where:publishPost
resolved sooner than what we wantedgetEditedEntityRecord
gets these edits.I think I got it right here with the flow.. --cc @youknowriad ?
This PR changes the util to wait for
PostPublishPanelPostpublish
.--edit seems PostPublishPanelPostpublish is not doing the trick and should find a better way to reliably know when a post is published..