-
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
Migrate block deletion E2E tests to Playwright #48012
Conversation
Size Change: 0 B Total Size: 1.33 MB ℹ️ View Unchanged
|
f5fcc04
to
5e70010
Compare
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.
Thank you! Really well written tests! Just left some nitpicks but overall it's good!
Note that changing the test titles means that the flaky tests reporter will no longer recognize them as the same test. If there are existing flaky test reports, we might want to close them after merging this.
Flaky tests detected in 9b27419. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4281813641
|
42495d5
to
a0d650a
Compare
GTK, thanks @kevin940726! To be sure, do the flaky reports depend on the title only or also on the filename (since we migrate from |
@kevin940726 performance specs are consistently failing with gutenberg/test/e2e/specs/editor/various/block-deletion.spec.js Lines 295 to 310 in aaf1276
|
Nope, they only depend on test title.
It's the same WordPress instance but a different browser instance. I don't think they will impact each other, unless |
Looks like it's not persistent. It also passes locally, unfortunately. 😞 I'll rerun and keep debugging. |
No wait, it's not even the same WordPress instance on CI 😅. |
I'm seeing the same perf specs failing on other branches as well (e.g. here and here), so it's not related to the current changes. It started happening just now, so I checked what changed recently and found 2 potential candidates: #47889 and #47777. The latter introduced a check that I'd normally mark as potentially flaky which might be causing the current issue. I'm trying out a fix on this PR here: 03d5b02. /cc @youknowriad edit: Testing in 2 other PRs as well: |
@WunderBart I have a similar suspicion as well. I opened this to try to debug it #48094 |
For some reason, my fix didn't work, we can try to go with yours if it works consistently. |
It looks like your proposed fix doesn't fix it either, so it must be something else. |
03d5b02
to
3f02486
Compare
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.
Thanks again! A couple of suggestions but none of blocking 🙂 .
await expect( | ||
editor.canvas.locator( '.is-multi-selected' ) | ||
).toHaveCount( 2 ); |
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.
Nit: I did a similar thing in #48035 using the getMultiSelectedBlocks
API. Maybe we can do something like that here?
await expect.poll( () =>
window.wp.data.select('core/block-editor').getMultiSelectedBlocks()
).toHaveCount( 2 );
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 guess we're not testing the multi-block selection here, so it's OK to validate programmatically! 👍
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.
Even if we do, I don't think .is-multi-selected
should be a public API for end users, so it should never be a testing target IMO.
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.
Could you elaborate on why you think it should not be a public API?
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.
It's a class that's never exposed to the users, nor to the plugin developers. On the other hand, getMultiSelectedBlocks
is a documented API. While it's still not a user-facing public API, but it's better than nothing I guess. A better way might be to check for accessible attributes, like aria-selected
or aria-current
, but that's probably not going to be available. The next option is visual testing, but not more difficult, and should only be tested once.
Co-authored-by: Kai Hao <kevin830726@gmail.com>
Not needed since Playwright v1.28
ad44813
to
9b27419
Compare
I just cherry-picked this PR to the wp/6.2 branch to get it included in the next release: caf09f1 |
What?
Migrate block deletion E2E tests to Playwright.
Why?
How?
Testing Instructions
The output of the following should be all ✅: