Перейти к содержимому

Тестирование веб-приложений 2.0
онлайн, начало 29 марта
Программирование на C# для тестировщиков
онлайн, начало 22 марта
Логи как инструмент тестировщика
онлайн, начало 25 марта
Тестирование производительности (JMeter)
онлайн, начало 22 марта
Фотография

Целесообразность WebDriverWait

Selenium WebDriverWait

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 Skull

Skull

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Andrii Cherepakha

Отправлено 12 Март 2019 - 15:00

Недавно посмотрел видео Алексея "Заморочки в 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 в своем выступлении использует такой подход.
 
QhMNrkA.jpg
 
Он не пишет "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. Стоит ли усилия результата?
 
 

  • 0

#2 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 310 сообщений
  • ФИО:Роман

Отправлено 12 Март 2019 - 15:47

может Вам надо на хабре статью написать?


  • 0

#3 Skull

Skull

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Andrii Cherepakha

Отправлено 12 Март 2019 - 15:58

может и на Харбе )) Для начала мне интересно мнение заинтересованной общественности :) 


  • 0

#4 Skull

Skull

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Andrii Cherepakha

Отправлено 14 Март 2019 - 15:56

может Вам надо на хабре статью написать?

 

Spock, спасибо за совет и мотивацию. Поправил, дополнил и разместил https://habr.com/ru/post/443754/


  • 1

#5 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 820 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 Март 2019 - 06:11

Дело в том, что в метод until передаётся функция, которая может быть определена где угодно (в том числе есть ряд предопределённых функций в классе ExpectedConditions). Да, если вы пишете лямбда-выражение -- скорее всего у вас в текущем контексте есть переменная, содержащая ссылку на драйвер. Но если вы используете заранее описанные условия ожидания -- ситуация меняется:

public class MyConditions {
  public static ExpectedCondition<Boolean> myCondition() {
    return new ExpectedCondition<Boolean>() {
      @Override
      public Boolean apply(WebDriver driver) {
        // вот сюда как раз будет передана ссылка на драйвер
      }
    }
  }
}
public class MyTest {
  WebDriver driver;

  @Test
  public void myTest() {
    new WebDriverWait(driver, 10).until(MyConditions.myCondition());
    // дождались!!!
  }
}

  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#6 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 820 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 Март 2019 - 06:13

Что касается возвращаемого значения -- оно очень даже используется, это происходит постоянно, если ожидания связаны с элементом:

wait.until(visibilityOfElementLocated(By.id("my-id")).click();

  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#7 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 310 сообщений
  • ФИО:Роман

Отправлено 15 Март 2019 - 08:20

наверное ответы лучше уже постить на хабр тоже, там дискуссия


  • 0

#8 Skull

Skull

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Andrii Cherepakha

Отправлено 15 Март 2019 - 14:24

Да, Алексей, спасибо. В связке с ExpectedCondition этот подход работать не будет. 


  • 0


Selenium 2.0: стартовый уровень
онлайн
Программирование на Java для тестировщиков
онлайн
Автоматизация функционального тестирования
онлайн
Selenium WebDriver: полное руководство
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале