О целесообразности Selenium WebDriverWait

[KSA]

Вас не смущает, что SpinUntil будет вызывать condition практически без интервалов?

[Andrii_Cherepakha]

Дельное замечание. Это единственная проблема этого подхода? :) У меня есть решение, я завтра обновлю статью.

[Andrii_Cherepakha]

Спасибо за замечание. Обновил.

[savkk]

То, что Simon Stewart использует в своем примере не ту переменную, скорее опечатка, а не правило. Не стоит на это обращать внимание.

Буду говорить за Java. Вообще вроде как всё логично.
Класс WebDriverWait расширяет класс FluentWait, который является реализацией интерфейса Wait. В интерфейсе Wait определен один метод — until, принимающий Funtion<? super T, V>, т.е. функцию с входным параметром T и выходным V. И это вроде как сделано не просто так, мы не должны завязываться на внешние переменные(доступные из «клиентского кода»), по этому в функцию передаем всё необходимое для её выполнения. Слабое связывание.

WebDriverWait в качестве T использует интерфейс WebDriver:

public class WebDriverWait extends FluentWait<WebDriver>

добавляет в igoring NotFoundException.class, т.е. игнорирует практически все исключения, которые могу быть вызваны при работе с WebDriver, а также переопределяет метод timeoutException, добавляя в сообщение диагностическую информацию по текущей сессии WebDriver'а.
Что из этого следует? А то, что в случае если WebDriver не нужен в контексте ожидания, используйте FluentWait с необходимым входным параметром.

[qwez]

И все же, вторая мысль — возвращаемое значение метода Until не используется в большинстве случаев.

Так и не понял откуда такой вывод. Если возвращает bool значение, то не нужно — тут ок. Если элемент, то нужно, чтобы еще раз не опрашивать драйвер. По этой логике в большинстве случаев мы хотим получать bool, но это же не так. Для поиска каждого элемента нужно ожидание. И в большинстве случаев мы все же будем использовать возвращаемое значение. Или я что-то не уловил?

[savkk]

Кстати да, забыл про это написать. Полностью поддерживаю!

[Andrii_Cherepakha]

Перефразируя свою мысль, я бы сказал, что возвращаемое значение только ради FindElement и существует. В случае bool и FindElements оно не несет смысловой нагрузки.

[savkk]

Вы совсем не правы. В классе ExpectedConditions есть еще как минимум один метод, возвращающий не Boolean и не WebElement, это метод alertIsPresent. Еще есть метод numberOfElementsToBeMoreThan, который прекрасно справляется со своей задачей и возвращает List элементов, есть visibilityOfAllElementsLocatedBy/visibilityOfAllElements, которые также нормально возвращают List элементов с проверкой на пустоту списка.

Возвращаемое значение не всегда требуется, но есть больше количество кастомных conditions с возвращаемыми объектами различных классов.

[Andrii_Cherepakha]

Я отнюдь не претендую на избавление ExpectedConditions или изменение WebDriverWait. Я говорю о том, что в один момент я понял, что «тяну» за собой экземпляр драйвера только лишь потому, что он мне нужен в WebDriverWait. И вместо этого я попробовал найти альтернативу.

Я скажу более, экземпляр драйвера вообще не нужен внутри Page Object (как тебе такое, Илон Маск? (с)). Вполне можно обойтись ISearchContext. Но в реализации этой идеи есть два камня преткновения: WebDriverWait и Actions. И если с первым решение есть, то со вторым надо еще побороться.

[savkk]

Не понимаю, какая разница SearchContext или WebDriver? Ну усекли вы возможности до 2 методов, а WebDriver то никуда не делся.
Всё взаимодействие с браузером осуществляется через него.
Когда вы ищите что-то из контекста WebElement'а, вы всё равно возвращаетесь к WebDriver'у.

[Andrii_Cherepakha]

IWebDriver остается на уровне класса базового теста. Он может передаваться в условные Navigation (используется .Navigate().GoToUrl()), в какие-то другие helpers (скажем, JavaScript executor), но в page object драйвер приходит в качестве ISearchContext. Это позволяет мне иметь один базовый класс SearchContextWrapper и для page object (всей страницы, «родитель» — корень DOM, IWebDriver) и для element object (логической части страницы, «родитель» — один из элементов страницы, IWebElement). И IWebElement, и IWebDriver реализуют ISearchContext. И на уровне SearchContextWrapper я не разделяю кем именно он является, ибо это уже становится не важным.

А если передавать IWebDriver, то приходится делить на что-то типа PageObject(IWebDriver parent) и PageElement(IWebElement paren, IWebDriver driverWillUseForWait). Можно, конечно, упороться и сделать PageElement(By paren, IWebDriver driverWillUseForSearchAndWait), но зачем, если есть ISearchContext.

Как-то так. А вообще это тема отдельной статьи :)

[savkk]

Это всё понятно, но почему бы не сделать свою реализацию, принимающую SearchContext, а не сомневаться в целесообразности в WebDriverWait?

[Andrii_Cherepakha]

Потому что есть случаи, когда он нецелесообразен :) Именно эту мысль я пытался донести.

[MrHant]

Зачем вообще оставлять привязку к селениуму в задаче «подождать чего-то»?

Одинакого плохо оставлять и IWebDriver и ISearchContext.

Не всегда Wait будет привязан к поиску чего-то.

[savkk]

Так для этого и существует FluentWait. Это просто готовое решение одной проблемы, не нравится, пишите свое. Честно, я вообще не понял суть статьи, проблема высосана из пальца

[MrHant]

Весь пакет Support является опциональным и просто взглядом разработчиков на то какие дополнительные вещи можно делать. ExpectedConditions в C# вообще использовать не стоит и аргументировать ими тоже — они deprecated и были просто пережитком того что в старых версиях Java не было лямбд.

Как по мне — дейтсивтельно лишним является только передача самого объекта IWebDriver внутрь ожидания, особенно если вы пишите какие-то абстрации вокруг драйвера.

Для себя сделал аналогичную реализацию, с немного другими фичами — github.com/MrHant/tiver-fowl.Waiting
Там нет протянутого IWebDriver, добавляется конфигурация, и прозрачное логирование. Так же вам может быть интересно возможность делать «Extended Wait» где проверка сразу не будет отваливаться по таймауту, а подождёт подольше и потом отметит тест как Warning (только для NUnit).

[moroz69off]

лишним является только передача самого объекта IWebDriver внутрь ожидания

Мне кажется, что передача драйвера в ожидание будет иметь смысл, когда у нас несколько+ экземпляров драйверов, и не все, например, StartSession, и внутри метода будет проверка. Или вообще нужны айди драйверов в ожидании — какой драйвер ждёт. ХЗ.