-
Notifications
You must be signed in to change notification settings - Fork 58
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
[RNMobile] Fix social icons block alignment #6146
[RNMobile] Fix social icons block alignment #6146
Conversation
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
@dcalhoun If you observe the updated image snapshots, you'll note that the top and bottom of the child Social Link block outline is cut off. As the child Social Link block outline is flush with the parent Social Icon block and looks nice in the Editor itself, I believe this cut off is likely due to the way the screenshot element is being selected: gutenberg-mobile/__device-tests__/gutenberg-editor-sanity-test-1-visual.test.js Lines 371 to 376 in 7da5853
Let me know if you have any ideas of a way around this, or if you feel this might be an acceptable limitation screenshotting an element. We could always just capture the entire Screen.Recording.2023-09-01.at.3.46.57.pm.mov |
I wasn't able to build the UI tests for iOS to capture the iOS image snapshots, which has been discussed on a separate issue at |
Padding accommodates the borders displayed on the Social Icon buttons.
These are a result of updates in the gutenberg submodule.
Padding accommodates for borders applied to Social Icon buttons.
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.
If you observe the updated image snapshots, you'll note that the top and bottom of the child Social Link block outline is cut off.
My recommendation would be to retain usage of takeScreenshotByElement
— it reduces the file size of snapshots and mitigates flaky tests — and leverage the padding
argument it offers. This will ensure the border is fully captured in the snapshot. I went ahead and implemented this approach in f9bfdf2.
I left a few comments and commits for your review as well. Let me know what you think. 🙇🏻
@@ -331,5 +331,54 @@ describe( 'Gutenberg Editor - Test Suite 1', () => { | |||
); | |||
expect( screenshot ).toMatchImageSnapshot(); | |||
} ); | |||
|
|||
it( 'should display the block outline of a block inserted from the appender', async () => { |
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.
While I recognize the block outline is a highly visual element, I might argue that while its presence is important its style is not critical. I posit we could/should merely assert the functionality succeeds in the form of asserting the outline's presence in a traditional integration test. I.e. we could add a testID
to the associated element and assert its presence rather than incurring the cost of an e2e visual snapshot test.
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.
I did consider the expense of the visual test, but I had not considered that the same behavior could be tested with an integration test asserting the presence of BlockOutline. As this current visual test addition asserts the behavior fixed in #6133, I suggest we keep the visual test and I can replace it with an integration test shortly afterward. Wydt?
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.
Sounds good. 👍🏻
@dcalhoun @derekblank I recently merged #6153 and changed the GitHub Checks. In other PRs, eg #6152, I took it upon myself to merge |
I hadn't considered the Thanks for making the updates! |
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 writing tests.
@mokagio I merged in
trunk
, and several of the CI tasks failed on CircleCI (example). The error seems to suggest that I needed to runnpm install
and commit the result, which updated the package.json in e4b87a1. Does it seem like these package.json changes be expected?
This relates to #6159. It should be safe to merge the changes.
CI tasks for the previous commit resulted in errors related to a duplicative Aztec module published for the commit SHA.
Related PRs
Description
This PR was generated by
version-toolkit
to downstream the changes forgutenberg
submodule.Additionally, this PR adds a UI test case to
gutenberg-editor-sanity-test-1-visual.test
to test the fix for #6133 and ensure a block outline is added for Social Link blocks added via the appender.