-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Add e2e testing for experimental nav menu deletion #38955
Add e2e testing for experimental nav menu deletion #38955
Conversation
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 for working on this, @chad1008 !
I left a few comments, although I'd prefer having another pair or eyes more experienced with e2e tests in this part of repo also have a look — cc;ing @getdave @talldan @Mamaduka who all have worked on this file before
Maybe they may also have an answer to the question that you raise in this PR's description re. the Jest did not exit one second after the test run has completed.
warning
const menuActionsDropdown = await page.waitForXPath( | ||
`//*[contains(@class,"edit-navigation-menu-actions")]//h2[text()="${ menuName }"]` |
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 was about to suggest that, instead of a classname, we'd look for the dropdown's toggle button instead (a button
with an aria-label
of Switch menu
, according to the code), but as I inspected the page locally, I realised the aria-label was not there.
That's because the label
should be applied as a prop of DropdownMenu
(i.e <DropdownMenu label={ __('Switch Menu') } ....
), and not as part of toggleProps
.
Once this PR is merged, we could open a follow-up PR where we fix this bug and we update the e2e introduced here to use the selector that I suggested above — WDYT ?
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.
Oh awesome! I was also looking for a non-class approach to this and didn't see anything I could point to... Thanks for sharing the context on why that was happening!
A followup PR sounds great, I'll put it on my to-do list once this merges!
const menuElementHandles = await page.$x( | ||
'//*[@role="group"]//*[@role="menuitemradio"]/span' | ||
); | ||
const existingMenus = []; | ||
for ( const elem of menuElementHandles ) { | ||
const elemName = await elem.getProperty( 'textContent' ); | ||
const existingMenuName = await elemName.jsonValue(); | ||
existingMenus.push( existingMenuName ); | ||
} | ||
expect( existingMenus.includes( `${ menuName }` ) ).toBe( | ||
false | ||
); |
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.
This part feels very "implementation details"-oriented.. maybe a better way to test for this is to (if I understand the purpose of this code):
- Create both menu1 and menu2
- Check that there is a dropdown entry (menuitemradio) for both menus
- Delete menu2
- Check that there is still a dropdown entry for the menu1
- Check for menu2 entry, expect the result to be
null
(or whatever the result should be when an element can't be found in the page)
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 suggestion. I pushed 26fbcc5. Unfortunately waitForXPath()
doesn't return anything when it fails to find an element, it just times out, throws an error and stops the test.
$x()
is meant to return an array of matching ElementHandles, which I could then try to call toContain()
against... but I had some trouble implementing it so I wound up falling back to waitForXPath()
and parsing TimeOut
errors as null
to serve as an indicator that the element isn't present. What do you think?
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'm not an expert about puppetteer APIs, but overall it seems a good enough approach.
My only comment, at this point, is regarding the verbosity of these checks — have you searched if there's already a shared util for performing such a check?
Alternatively, we could simply refactor the logic into a getMenuItem( menuItemName )
function, on top of my head something like:
const getMenuItem = async ( menuItemName ) =>
await page
.waitForXPath(
`//*[@role="group"]//*[@role="menuitemradio"]/span[text()="${ menuItemName }"]`
)
.catch( ( error ) => {
if ( error.name !== 'TimeoutError' ) {
throw error;
} else {
return null;
}
} );
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 haven't seen any similar shared utilities to easily check for the existence of an element, but I like your refactoring suggestion, thank you! pushed f6a2f44 :)
Sorry, I just saw this. I think all the Navigation Editor end to end tests are skipped right now as the editor is mostly broken state. It probably shouldn't be something users can enable right now. I don't think these tests will run while they're nested in the top level It does look like the menu creation and deletion process still works, so un-nesting specific tests from that top level |
3d3c79a
to
e7653f3
Compare
No worries @talldan! I saw the main describe was skipped (which makes sense for an experimental UI) but figured it'd make sense to have tests prepped for the new In terms of un-nesting, I'm open to whatever more experienced Gutenberg contributors think there. Is it better to keep this nested and skipped until the UI actually starts being used? Or unnest them so they'll get incrementally improved as things change around them? |
If I understand what @talldan intended, I think it would be ok to un-nest (i.e. move them under a separate
What do you think ? |
e7653f3
to
f6a2f44
Compare
Sounds good to me. I found there was one failing test and several obsolete snapshots in the menu creation tests, so I've left them where they are for now, and separated out the new tests for the delete menu button. 2c48c25 |
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.
LGTM 🚀 Thank you for working on this!
I've decided to skip them in #39746. I did have a look to see if I could figure out what the issue is. I'm not sure though. Potentially it could be related to the 'Theme locations' panel above the Delete button. That panel content loads in dynamically, so the test could be trying to click while the browser is still laying out the sidebar content—the element might be moving out from the position that the test is clicking in. If we can figure out what it is then we can look at re-enabling them. |
Thanks @talldan. Pausing for now definitely seems like the right move, especially where this is a UI that isn't in use yet. I'll put looking into those failures on my todo list. Your theory about the theme locations sounds solid, I'll start there. |
Description
Follow up to #37492
This PR adds e2e tests for menu deletion, and the newly migrated ConfirmDialog, in the experimental nav editor. It tests:
The above are all tested twice, once for large and once for small viewports.
The confirmation test happens in two different contexts because the flow is different. With no other menus, we're shown the "Create your first menu" prompt, while if additional menus remain after deletion, we should simply see one of the other menus instead.
Edited to add:
I initially forgot to mention, I do see frequent (not constant, but on a lot of test runs) warnings from Jest:
In troubleshooting, I've found this comes up inconsistently with existing tests in the suite as well. The more tests you run the more likely you are to see it, so with this PR's six tests it comes up a lot.
I think it's being triggered by something in the timing of the
createMenu()
method's API call, but that's just a theory. Either way it feels like something best pursued in a separate PR.Testing Instructions
.skip
frompackages/e2e-tests/specs/experiments/navigation-editor.test.js
line 181..only
to thedescribe
call. This is both to speed up testing and also to skip over issues that appear to be present in some of the existing tests.npx wp-scripts test-e2e --config packages/e2e-tests/jest.config.js packages/e2e-tests/specs/experiments/navigation-editor.test.js
Checklist:
*.native.js
files for terms that need renaming or removal).cc @ciampo @fullofcaffeine