-
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
Add interface preferences modal to edit post. #39176
Conversation
Size Change: +6 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
343aea1
to
6c1532d
Compare
6c1532d
to
ce36ab5
Compare
|
||
// This allows us to tweak the returned value on each test. | ||
jest.mock( '@wordpress/data/src/components/use-select', () => jest.fn() ); | ||
jest.mock( '@wordpress/compose/src/hooks/use-viewport-match', () => jest.fn() ); | ||
|
||
describe( 'PreferencesModal', () => { | ||
describe( 'EditPostPreferencesModal', () => { |
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 sure how useful these snapshots actually are as tests 🤷
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.
Yeah, I agree. We should be making explicit assertions rather than blindly comparing snapshots. Or maybe just remove them if they aren't helpful 🤷♂️.
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.
Same, I think there's a fair few component tests that are pretty much "Does it render" and used the snapshot approach to avoid having to write more detailed usability-focused tests. It'd be nice to follow-up at some point to add React Testing Library-based tests that more closely look at how the component's used (e.g. tabbing on larger viewports vs navigation in narrower ones, etc). For the moment, sticking with the snapshots sounds good to me, though, to avoid doing too much in the one PR.
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.
Yeah, I'm thinking the best way to test something like this might be e2e, but best look at that in another PR 😅
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.
@@ -54,7 +54,7 @@ async function waitForPreviewNavigation( previewPage ) { | |||
* @param {boolean} shouldBeChecked If true, turns the option on. If false, off. | |||
*/ | |||
async function toggleCustomFieldsOption( shouldBeChecked ) { | |||
const baseXPath = '//*[contains(@class, "edit-post-preferences-modal")]'; | |||
const baseXPath = '//*[contains(@class, "interface-preferences-modal")]'; |
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.
Off-topic, just jogging my thoughts down: A good example of having class names in e2e selectors isn't a good idea. We could probably just do [role="dialog"]
here, since there should be only one dialog/modal usable at any given time. It's not very readable what this modal is though, so an accessible role selector is still useful: role=dialog[name="Preferences"]
|
||
// This allows us to tweak the returned value on each test. | ||
jest.mock( '@wordpress/data/src/components/use-select', () => jest.fn() ); | ||
jest.mock( '@wordpress/compose/src/hooks/use-viewport-match', () => jest.fn() ); | ||
|
||
describe( 'PreferencesModal', () => { | ||
describe( 'EditPostPreferencesModal', () => { |
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.
Yeah, I agree. We should be making explicit assertions rather than blindly comparing snapshots. Or maybe just remove them if they aren't helpful 🤷♂️.
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 is testing well for me, too! Should we also remove the CSS rules that were duplicated in #39153 (e.g. around this line?)
Oooh well spotted! Done ✅ |
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 good to merge 👍
Thanks for working on this!
+1! Thanks for removing the extra CSS, too! ✨ |
Description
Replaces the edit post preferences modal with the reusable one from the interface package added in #39153.
Testing Instructions
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.js
files for terms that need renaming or removal).