Htmlelements: как лучше организовать ожидания

webdriver
, , ,
#21

Ну во-первых, зачем вам FluentWait, если WebDriverWait уже итак его наследует?

Во-вторых, зачем усложнять, осуществляя поиск по GitHub, если можно прямо в IDEA через Ctrl заглянуть в любой класс драйвера, и в адекватном редакторе посмотреть все взаимосвязи?

В третьих, смотреть нужно глубже, т.к. чуть ли не первой инструкцией в обоих методах идет вызов совершенно разных хэлперов: visibilityOfElementLocated vs visibilityOf.

Когда узрите разницу, перечитайте еще раз, по какой причине возникает StaleElementReferenceException, и попробуйте связать все это воедино.

1 лайк
#22

Подитожу что я понял:
разница хэлперов: visibilityOfElementLocated vs visibilityOf в том,что первый ищет елемент в DOMе и,соответственно ловит StaleElementReferenceException

try {
     return elementIfVisible(findElement(locator, driver));
    } catch (StaleElementReferenceException e) {
      return null;
    }

второй же просто возвращает обертку над element.isDisplayed() ? element : null;

 return elementIfVisible(element);

Когда же этот StaleElementReferenceException вылетает :

A StaleElementException is thrown when the element you were interacting is destroyed and then recreated. Most complex web pages these days will move things about on the fly as the user interacts with it and this requires elements in the DOM to be destroyed and recreated.

When this happens the reference to the element in the DOM that you previously had becomes stale and you are no longer able to use this reference to interact with the element in the DOM. When this happens you will need to refresh your reference, or in real world terms find the element again.

То бишь,поля (поллинг) DOM мы получаем всегда свежий результат для взаимодействия с елементом при использовании By и возможность получить “черствую булочку” в виде елемента который только опрашивается на isDisplayed().
Это касательно visibility,но,думаю,в других кондышенах суть та же.
Если ошибся или есть дополнения буду благодарен.

P.S. Наверное я путаюсь так как не могу технически понять разницу между механизмами
“переискивать” и “опрашивать”.
Как понимаю : при первом действии,как писал выше “получаем всегда свежий результат для взаимодействия”,при втором обращаемся к состоянию которое было на момент нахождения елемента.Но это состояние может изменится,ведь для етого мы используем вейтер.То есть,для профилактики StaleElementException мне очевидно преимущество,а для других нет.
И @FindBy ищет елемент только при обращении ,а не когда-то нашол и все время использует.

#23

Только практика поможет вам разобраться в таком случае. Возьмите, к примеру, какой-то кастомный Select2 с динамической фильтрацией элементов, и поиграйтесь с ним.