Недавно посмотрел видео Алексея "Заморочки в Selenium WebDriver". Я ждал более технических моментов, по типу staleness. Один из таких хотелось бы обсудить. А именно, есть ли реальная необходимость в классе WebDriverWait и его основном методе Until.
Все последующие размышления основаны на исходном коде C#.
При создании экземпляра WebDriverWait в конструктор передается экземпляр драйвера, который сохранятеся во внутреннем поле input. Метод Until предполагает делегат, входным параметром которого должен быть IWebDriver, экземпляром которого и является input.
Я задаюсь вопросом зачем такие сложности, нужен ли вообще WebDriverWait и можно ли от него отказаться?
Давайте посмотрим на исходный код метода Until. Костяк его логики - это бесконечный цикл с двумя условиями выхода из него: наступление нужного события или timeout. Дополнительными "плюшками" являются игнорирование предопределенных exceptions и возврат объекта, если в качестве TResult выступает не bool (об этом чуть позже).
Первый ограничение, которое я вижу - нам всегда требуется именно экземпляр IWebDriver, хотя внутри метода Until (если быть точным, то в качестве входного параметра для condition) мы могли бы вполне обойтись ISearchContext. Ведь в большинстве случаев мы ожидаем какого-то элемента или изменения его свойства и используем FindElement(s) для его поиска.
Я рискну заявить, что использование ISearchContext было бы даже более логичным, ведь клиентский код (класс) - это не только page object, который в поиске дочерних элементов отталкивается от корня страницы. Иногда это класс, описывающий некий составной элемент, у которого корнем является другой элемент страницы, а не сама страница. В качестве такого примера можно привести SelectElement, который принимает в конструктор ссылку на родительский IWebElement.
Вернемся к вопросу инициализации WebDriverWait. Это действие требует экземпляр драйвера. Т.е. нам всегда, так или иначе, в клиентский код необходимо извне пробрасывать экземпляр IWebDriver, даже если это класс некоего составного элемента (пример про SelectElement), который уже принимает "родителя". С моей точки зрения, это излишне.
Конечно, мы можем создать класс по аналогии
SearchContextWait : DefaultWait<ISearchContext>Но не будем торопиться. Он нам не понадобится.
Давайте посмотрим, как используется передаваемый в condition экземпляр драйвера. Обычно это выглядит как-то так:
var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10));
wait.Until( d => d.FindElements(By.XPath("locator")).Count > 0 );
Возникает вопрос, зачем внутри condition необходима "локальная" версия драйвера, если он всегда доступен из клиентского кода? Более того, это тот же самый экземпляр, переданный ранее через конструктор. Т.е. код может выглядет как-то так:
var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10));
wait.Until( d => Driver.FindElements(By.XPath("locator")).Count > 0 );
Даже Simon Stewart в своем выступлении использует такой подход.
Он не пишет "d -> d.", а пишет "d -> driver.", т.е. переданный внутрь метода экземпляр драйвера попросту игнорируется. Но передавать его необходимо, ибо этого требует сигнатура метода!
Итак, зачем же передавать драйвер во внутрь condition метода? Возможно, чтобы изолировать поиск внутри этого метода, как это реализовано в ExpectedConditions? Посмотрите на реализацию метода TextToBePresentInElement. Или VisibilityOfAllElementsLocatedBy. Или TextToBePresentInElementValue. В них переданный драйвер даже не используется!
Итак, первая мысль - нам не нужен метод Until с параметром-делегатом, который принимает драйвер.
Давайте теперь разберемся, нужено ли методу Until возвращаемое значение? Если в качестве TResult выступает bool, то нет, не нужно. Ведь в случае успеха вы получите true, а в случае неудачи вы получите TimeoutException. В чем информативность такого поведения?
А если в качестве TResult выступает object? Предположим, такую конструкцию:
var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); wait.IgnoreExceptionTypes(typeof(NoSuchElementException)); var element = wait.Until(d => d.FindElement(xpath));
Т.е. мы не только ждем появления элемента, а и используем его (если дождались), тем самым убирая одно лишнее обращение к DOM. OK.
Давайте посмотрим пристальнее на эти три строчки кода. Внутри реализации метода Until это сводиться к некоему подобию (условный код)
try { FindElement } catch (NoSuchElementException) {}
Поскольку генерация exception довольно дорогостоящее событие, то я бы предпочел его избегать, особоенно в тех местах, где это не представляет труда. Мы можем переписать код следующим образом:
var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(10)); var elements = wait.Until(d => d.FindElements(xpath));
Т.е. мы используем FindElements, который не генерирует исключение. Подождите, а будет ли эта конструкция ждать появления элементов? НЕТ! Потому что, если посмотреть в исходный код, выполнение бесконечного цикла завершает сразу, как только condition возвращает не null. А FindElements в случае неудачи возвращает пустую колекцию, но никак не null. Т.е. для списка элементов использование Until не имеет смысла.
Вторая мысль - возвращаемое значение метода Until не используется в большинстве случаев.
Передаваемое значение излишне, возвращаемое значение не используется. В чем же полезность Until? Только лишь в цикле и периодичности вызова condition метода? Этот подход уже реализован в C# в методе SpinWait.SpinUntil. Единственное его отличие, что он не генерирует исключение по timeout. Это можно исправить следующим образом:
public void Wait(Func<bool> condition, TimeSpan timeout)
{
var waited = SpinWait.SpinUntil(condition, timeout);
if (!waited)
{
throw new TimeoutException();
}
}
Т.е. эти несколько строк кода в большистве случаев заменяют логику работы WebDriverWait. Стоит ли усилия результата?
