-
-
Notifications
You must be signed in to change notification settings - Fork 230
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
Implementation of the 'scroll' command #244
Implementation of the 'scroll' command #244
Conversation
Can you add some test cases if you have a time? Line 194 in ce4b766
|
Nicely done. Having a test would be perfect. |
…f swipes allowed during scroll operations.
…iSelector spec, horizontal scroll, scroll with limited and unlimited number of swipes). Renamed DeviceCommands.scrollTo() to DeviceCommands.scrollToText().
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/BaseTest.java
Outdated
Show resolved
Hide resolved
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/BaseTest.java
Outdated
Show resolved
Hide resolved
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/BaseTest.java
Outdated
Show resolved
Hide resolved
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/TestUtils.java
Outdated
Show resolved
Hide resolved
...dTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/commands/DeviceCommands.java
Outdated
Show resolved
Hide resolved
…method scrollToText().
…ccessfully that might fail automated build jobs. Removed @ignore attribute added by mistake to test shouldShutdownServerOnPowerDisconnect.
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/DeviceCommandsTest.java
Show resolved
Hide resolved
…e comparison of values.
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/internal/BaseTest.java
Outdated
Show resolved
Hide resolved
It looks like |
…s, and log messages.
… 23 and earlier. Simplified test cases scrollVeryLongListSuccessfully and scrollVeryLongListUnsuccessfully. Fixed some code-formatting issues.
… to the target page.
app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/DeviceCommandsTest.java
Show resolved
Hide resolved
The tests are still failing on Travis. Please note that Travis performance is not very good, since it can only run arm-based AVD, which requires to put longer timeouts or more retries for e2e tests in comparison to a local run. I like the recent source fixes. |
Hmmm, the CI tests that fail were not touched by this change at all. |
…ht have been be responsible for CI test failures.
…estigate strange failures in CI tests.
In the latest push I replaced calls to navigateTo() - a new method introduced in this pull request - with startActivity() - a method used by other tests that were not touched by this change. UPDATE: The same tests still fail. So, the culprit is not the navigateTo() method. When run locally on fast and slow (ARM) emulators, all tests run with no problems and pass consistently 100%. My latest guess is that there is something with the API Demos app that is used in CI tests on Travis. Is there a way to check if I am using the right target app in my local setup? |
There is only one failing test. If it passes locally then I assume we might mark it as ignored for now and add a comment that it's unstable on CI. |
…he scrolling that uses a non-default value.
There are two tests that fail, and the reason for the failures seem to be the small number of maximum search swipes set in one of the tests that runs before the failing ones. The number of search swipes is held in a static property of the UiScrollable class. That is, whenever a non-default number of search swipes is used during the scroll, we must always restore the setting after the operation. Otherwise all subsequent scrolls will use the new value, which might not be good. I believe, this is exactly what happens in the failing CI tests. The latest update addresses this issue. |
…calls to a more efficient startActivity(). Removed the 'import' statements that became unnecessary because of this change. Updated logic in the scrollByClassName() test to properly handle premature failures.
…ntees proper restoration of the maxSearchSwipes value.
This change fixes implementation of the ScrollTo command, so that now it supports different strategies to search for a GUI element (by accessibility id, by class name, and by using the Android uiautomator selectors). The fix also addresses issue #98. Please let me know if I missed something in the implementation, and/or more files need to be updated.
Command: POST /session/:sessionId/touch/scroll
Here are a few examples of the supported JSON objects in the body of the POST request:
Scroll to an element using its accessibility id:
Scroll to an element using its class name:
Scroll to an element identified by an Android uiautomator selector - 'element's text contains given string':
Scroll to an element identified by an Android uiautomator selector - 'element's content-desc is the given string':