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.
Partially addresses #1662
Summary
This PR addresses some of the Android e2e flakiness. In particular, it should resolve the issue where only a part of the desired text would be input on the device, resulting in an expectation failure where the actual text was only the beginning of the expected text.
In short, this PR avoids using ADB to insert text when possible because that was found to not work consistently. For reasons discussed below, we still needed to use ADB to insert text when we wanted to append text, but there are only a few cases where that is necessary (list blocks), and the text being appended there is very short. If that ends up being a problem, we could always just disable the list tests on Android until a better solution is found.
What this PR does NOT do
"Requested environment is unavailable error"
This PR does not address the "requested environment is unavailable" error. I originally believed this error was entirely due to the saucelabs queue getting backed up. I still think that is probably the issue some of the time, but I have since observed the environment unavailable error occur when the saucelabs queue was empty (and the error occurred before saucelabs received a request to run tests, i.e., there was no record of the test on saucelabs).
Rotation test issues
In addition, since upgrading our RN to version 61.5, I have seen intermittent errors locally the rotation tests. I was able to reproduce this error locally even with the changes in this PR, so I don't think this PR will fix that (although I cannot seem to reproduce that error now). In addition, @hypest reported observing these same errors on CI before the RN version upgrade, so it sounds like this issue may be an unrelated to the upgrade.
Background
Using ADB to insert text
In testing, I observed that even locally sometimes only the beginning of the text passed to ADB would get entered. I initially investigated trying to get ADB to work more consistently, but I was not able to find a way to avoid this.
Using Appium's
type
(aka sendKeys) apiiOS uses the
type
method for entering text. The reason Andorid has not been using thetype
method is because (only on Android) thetype
method deletes all of the text in theEditText
before entering the new text. That alone wouldn't be that big of a problem but, in our app, it also removes the block entirely. This means that anytime we tried totype
into a block, the block would be removed before the test tried to add the text to the block, resulting in the test throwing an error on account of the missing block. This is why we were using ADB.It turns out, however, that as long as the block contains some text, then the block is not removed. Therefore, in this PR, I am using ADB to insert a single space into a block before using the
type
API, which removes that space (but not the entire block) and then inserts the desired text. If we want to append text however, we still must use ADB. Fortunately, at this point the list block tests are the only tests that require appending text. This is because with list blocks thetype
api "clears" the list bullet, which seems to corrupt the block.One nice side benefit of using the
type
api more, is that it seems to enter text a fair bit quicker than ADB, so it speeds up the e2e tests a bit.A Possible Alternative Approach
One possible alternative approach would be to have Android only use the
type
api and simply disable the list tests on Android since those are the only tests that require the ability to append text. I'm trying to avoid this solution because it both (1) reduces Android's test coverage and (2) prevents us from writing any new tests that need "append" type behavior. If, however, we find there are issues with the approach taken with this PR, it may be worth considering this as an alternative.To Test
Confirm that e2e tests pass on both platforms.
At the time I moved this from being a draft PR to being Ready for Review, the Android e2e tests for the complete set of changes in this PR has passed all 10 times I ran it on CI (the old failures of this PR were when I was still working on the fix) and many more times locally. Interestingly, there was one failure with these changes on CI, but this was on iOS and I suspect it was unrelated to this PR.
PR Submission Checklist
RELEASE-NOTES.txt
if necessary.