Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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] - Add waits to fix editor test flakiness #39668
[RNMobile] - Add waits to fix editor test flakiness #39668
Changes from 3 commits
8885da0
dc4337d
1e6fcbc
9541748
8fb37dc
c1c5296
1b6d50c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Moved to use
XPath
instead ofaccessibilityId
because if anaccessibilityId
is not found, the Appium session is immediately terminated giving no chance to wait and retry. While XPaths are not recommended locators, it is the workaround for this case for now.Let me know if anyone knows of a better alternative!
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.
True, it's generally not recommended to use
XPaths
but I wouldn't oppose using it if there's no other option. I haven't investigated other approaches, but I recall that WebDriver automatically finishes the session upon some failures, even if the call is wrapped withtry-catch
😞 .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 tried wrapping it in a try-catch, hoping to bypass the error but it didn't work 😞 I also checked if it was configurable but looks like it isn't.
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 seems to only be affecting Android tests, there could be more but for this test file, looks like Image block is one of them. The locator is the part highlighted below:
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.
Media blocks like Image automatically open the media options picker. In this case, I think that waiting for the block picker should be part of the test that adds the block. Which by the way is already being done, as outlined in the following example:
gutenberg/packages/react-native-editor/__device-tests__/gutenberg-editor-image-@canary.test.js
Lines 10 to 12 in a4c8730
Although it would be great to use the
waitForVisible
helper for that element (i.e. media options picker) too 😅 .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.
Ah ok, I was actually looking to find what that was called. I'll update this to move to
closePicker()
I think would make more sense there so that it covers all media blocks.I think the implicit waits on the tests can then be removed with this change, but I'll do that in a future PR so that this PR can focus on this one test file first.
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.
For now, I've set that it waits for the Paragraph block to load because it's the first one on the blocks list, I'm not sure how often the list changes so this has the potential to fail in the future. Another option is to wait for the search box. What do you all 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.
The block picker view has a
testID
attribute with valueadd-block-button
, maybe we should rely on that, wdyt?As an alternative, we might consider adding accessibility info, which apart from helping us query the element, would be a good improvement in terms of a11y.
gutenberg/packages/block-editor/src/components/inserter/index.native.js
Line 50 in 41325b9
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.
Ah ok but looks like that is before the block picker view:
After some investigation, looks like we can actually create another wait helper that uses IDs! But it has to be an ID defined like this (i.e For Android,
android:id/{value}
):There is an open issue for this here. Appium doc how to use this here.
I am not sure where this is defined (looks like not on the
./index.native.js
file), if we can add an ID on a more appropriate view we could depend on that to load first before continuing the test.I think, for now, I will leave it to wait for Paragraph block before continuing the test. Future improvements (i.e. add id and use it for the test) to be done in a separate PR. Is that ok?
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 sorry, I'm afraid I referenced the wrong test ID. The one I'm wanted to share is
InserterUI-Blocks
:gutenberg/packages/block-editor/src/components/block-types-list/index.native.js
Line 89 in 41325b9
In any case, I think it's quite reliable to use the Paragraph block as it's a block that will be always present.