Comments 17
Вас не смущает, что SpinUntil будет вызывать condition практически без интервалов?
То, что Simon Stewart использует в своем примере не ту переменную, скорее опечатка, а не правило. Не стоит на это обращать внимание.
Буду говорить за Java. Вообще вроде как всё логично.
Класс WebDriverWait расширяет класс FluentWait, который является реализацией интерфейса Wait. В интерфейсе Wait определен один метод — until, принимающий Funtion<? super T, V>, т.е. функцию с входным параметром T и выходным V. И это вроде как сделано не просто так, мы не должны завязываться на внешние переменные(доступные из «клиентского кода»), по этому в функцию передаем всё необходимое для её выполнения. Слабое связывание.
WebDriverWait в качестве T использует интерфейс WebDriver:
добавляет в igoring NotFoundException.class, т.е. игнорирует практически все исключения, которые могу быть вызваны при работе с WebDriver, а также переопределяет метод timeoutException, добавляя в сообщение диагностическую информацию по текущей сессии WebDriver'а.
Что из этого следует? А то, что в случае если WebDriver не нужен в контексте ожидания, используйте FluentWait с необходимым входным параметром.
Буду говорить за 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 с необходимым входным параметром.
И все же, вторая мысль — возвращаемое значение метода Until не используется в большинстве случаев.
Так и не понял откуда такой вывод. Если возвращает bool значение, то не нужно — тут ок. Если элемент, то нужно, чтобы еще раз не опрашивать драйвер. По этой логике в большинстве случаев мы хотим получать bool, но это же не так. Для поиска каждого элемента нужно ожидание. И в большинстве случаев мы все же будем использовать возвращаемое значение. Или я что-то не уловил?
Кстати да, забыл про это написать. Полностью поддерживаю!
Перефразируя свою мысль, я бы сказал, что возвращаемое значение только ради FindElement и существует. В случае bool и FindElements оно не несет смысловой нагрузки.
Вы совсем не правы. В классе ExpectedConditions есть еще как минимум один метод, возвращающий не Boolean и не WebElement, это метод alertIsPresent. Еще есть метод numberOfElementsToBeMoreThan, который прекрасно справляется со своей задачей и возвращает List элементов, есть visibilityOfAllElementsLocatedBy/visibilityOfAllElements, которые также нормально возвращают List элементов с проверкой на пустоту списка.
Возвращаемое значение не всегда требуется, но есть больше количество кастомных conditions с возвращаемыми объектами различных классов.
Возвращаемое значение не всегда требуется, но есть больше количество кастомных conditions с возвращаемыми объектами различных классов.
Я отнюдь не претендую на избавление ExpectedConditions или изменение WebDriverWait. Я говорю о том, что в один момент я понял, что «тяну» за собой экземпляр драйвера только лишь потому, что он мне нужен в WebDriverWait. И вместо этого я попробовал найти альтернативу.
Я скажу более, экземпляр драйвера вообще не нужен внутри Page Object (как тебе такое, Илон Маск? (с)). Вполне можно обойтись ISearchContext. Но в реализации этой идеи есть два камня преткновения: WebDriverWait и Actions. И если с первым решение есть, то со вторым надо еще побороться.
Я скажу более, экземпляр драйвера вообще не нужен внутри Page Object (как тебе такое, Илон Маск? (с)). Вполне можно обойтись ISearchContext. Но в реализации этой идеи есть два камня преткновения: WebDriverWait и Actions. И если с первым решение есть, то со вторым надо еще побороться.
Не понимаю, какая разница SearchContext или WebDriver? Ну усекли вы возможности до 2 методов, а WebDriver то никуда не делся.
Всё взаимодействие с браузером осуществляется через него.
Когда вы ищите что-то из контекста WebElement'а, вы всё равно возвращаетесь к WebDriver'у.
Всё взаимодействие с браузером осуществляется через него.
Когда вы ищите что-то из контекста WebElement'а, вы всё равно возвращаетесь к WebDriver'у.
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.
Как-то так. А вообще это тема отдельной статьи :)
А если передавать IWebDriver, то приходится делить на что-то типа PageObject(IWebDriver parent) и PageElement(IWebElement paren, IWebDriver driverWillUseForWait). Можно, конечно, упороться и сделать PageElement(By paren, IWebDriver driverWillUseForSearchAndWait), но зачем, если есть ISearchContext.
Как-то так. А вообще это тема отдельной статьи :)
Зачем вообще оставлять привязку к селениуму в задаче «подождать чего-то»?
Одинакого плохо оставлять и IWebDriver и ISearchContext.
Не всегда Wait будет привязан к поиску чего-то.
Одинакого плохо оставлять и IWebDriver и ISearchContext.
Не всегда Wait будет привязан к поиску чего-то.
Весь пакет Support является опциональным и просто взглядом разработчиков на то какие дополнительные вещи можно делать. ExpectedConditions в C# вообще использовать не стоит и аргументировать ими тоже — они deprecated и были просто пережитком того что в старых версиях Java не было лямбд.
Как по мне — дейтсивтельно лишним является только передача самого объекта IWebDriver внутрь ожидания, особенно если вы пишите какие-то абстрации вокруг драйвера.
Для себя сделал аналогичную реализацию, с немного другими фичами — github.com/MrHant/tiver-fowl.Waiting
Там нет протянутого IWebDriver, добавляется конфигурация, и прозрачное логирование. Так же вам может быть интересно возможность делать «Extended Wait» где проверка сразу не будет отваливаться по таймауту, а подождёт подольше и потом отметит тест как Warning (только для NUnit).
Как по мне — дейтсивтельно лишним является только передача самого объекта IWebDriver внутрь ожидания, особенно если вы пишите какие-то абстрации вокруг драйвера.
Для себя сделал аналогичную реализацию, с немного другими фичами — github.com/MrHant/tiver-fowl.Waiting
Там нет протянутого IWebDriver, добавляется конфигурация, и прозрачное логирование. Так же вам может быть интересно возможность делать «Extended Wait» где проверка сразу не будет отваливаться по таймауту, а подождёт подольше и потом отметит тест как Warning (только для NUnit).
лишним является только передача самого объекта IWebDriver внутрь ожидания
Мне кажется, что передача драйвера в ожидание будет иметь смысл, когда у нас несколько+ экземпляров драйверов, и не все, например, StartSession, и внутри метода будет проверка. Или вообще нужны айди драйверов в ожидании — какой драйвер ждёт. ХЗ.
Sign up to leave a comment.
О целесообразности Selenium WebDriverWait