UiScrollable scrollIntoView останавливается непосредственно перед прокруткой в ​​представление - PullRequest
Новая
       71

UiScrollable scrollIntoView останавливается непосредственно перед прокруткой в ​​представление

1 голос
/ 21 января 2020

Я создал следующую обертку UiScrollable для android тестирования: 

protected fun UiScrollable.ensureScrolledIntoView(elementToScrollTo: UiObject) {
    val elementPresent = scrollIntoView(elementToScrollTo)
    if (!elementPresent) {
        Assert.fail("Expected element ${elementToScrollTo.selector} not found in scroll view")
    }
}

Я считаю, что сама обертка не является проблемой, но иногда scrollIntoView не может сделать последнее необходимое прокрутки пролистать. Лучше всего продемонстрировать на примере:

Illustration example

Выдает ошибку:

java .lang.AssertionError: Ожидается элемент UiSelector [CLASS = android .widget.LinearLayout, DESCRIPTION = May, CHILD = UiSelector [TEXT = 7, RESOURCE_ID = com.maypackage. android: id / calendar_day_text_view]] не найден в виде прокрутки

И это, очевидно, было поручено прокрутить до 7 мая.

Иногда происходит то же самое, когда я ищу дату, которая будет найдена с прокруткой вверх: метод возвращает только одну короткую прокрутку и элемент не найден.

Кто-нибудь сталкивался с такой проблемой? Как это побороть?

1 Ответ

0 голосов
/ 11 февраля 2020

EDIT

После долгих экспериментов я обнаружил, что проблема заключается в элементах на экране, потребляющих определенные попытки прокрутки. Это легче всего испытать в случае плавающих кнопок, но ситуация вопроса показывает более неясный пример того же самого. В большинстве случаев оказалось, что setSwipeDeadZonePercentage на UiScrollable помогло мне. Этот метод говорит прокручиваемому, что есть определенная область, в которой не следует предпринимать попытки считывания. Это решило проблемы в случае переполнения кнопок. Для более неясных случаев я использую метод, описанный ниже, который все еще не гарантированно работает, но в моих случаях он стабилен.

СТАРЫЙ, оригинальный ответ:

В конце концов, через много испытания Я обнаружил, что ошибка структуры является более общей c и не обязательно вызывает остановку одним движением, прежде чем элемент будет в представлении. Честно говоря, я считаю, что проблема заключается в нестабильном поведении метода scrollForward, который используется внутри метода scrollIntoView. В конце концов я переписал свой метод следующим образом: 

protected fun UiScrollable.ensureScrolledIntoView(elementToScrollTo: UiObject) {
    // this method used to use scrollIntoView, but it proved unstable
    if (elementToScrollTo.exists()) return
    while (scrollBackward()) {
        // no body needed
    }

    // very complex construct, because scroll forward seems to return false on first call
    var consecutiveFailingScrolls = 0
    while (consecutiveFailingScrolls < 2) {
        if (elementToScrollTo.exists()) return
        if (!scrollForward()) {
            consecutiveFailingScrolls++
        } else {
            consecutiveFailingScrolls = 0
        }
    }
    Assert.fail("Expected element ${elementToScrollTo.selector} not found in scroll view")
}

Это в основном пытается устранить нестабильность фреймворка, и до сих пор он меня не подводил. Кстати, я подозреваю, что нестабильность scrollIntoView проявляется только тогда, когда мы прокручиваем лениво загружаемые компоненты, такие как представления переработчика. На данный момент я намереваюсь продолжить использование библиотечных методов для не ленивых загрузочных списков и посмотреть, встречаются ли другие ошибки.

...