Теория большого вейта

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

Если вы читали документацию Selenide, вы уже знаете, что классические явные ожидания типа

element = (new WebDriverWait(driver, <timeOutForElement>))
  .until(ExpectedConditions.presenceOfElementLocated(By.cssSelector(<cssSelector>)));

или

element = (new WebDriverWait(driver, <timeOutForElement>))
  .until(ExpectedConditions.visibilityOfElementLocated(By.cssSelector(<cssSelector>)));

были заменены в Selenide более коротким конструкциями типа

element = $(<cssSelector>).should(exist);
element = $(<cssSelector>).shouldBe(visible);

Как известно, ассерты в Selenide - это новая версия явных ожиданий, что хорошо описано в документации.

Сегодня мы не будем рассматривать ожидания и ассерты с технической точки зрения, а подумаем, для чего можно использовать ассерты в различных ситуациях.

Современные проблемы требуют современных решений

1. Thread.sleep()

Это самое ужасное, что может случиться с нашими тестами на Selenium.

В некоторых ситуациях мы были вынуждены использовать слипы. У нас просто не было другого решения, чтобы обойти проблему и двигаться дальше. Например, слипы используют, чтобы дождаться окончания загрузки страницы. Иногда - чтобы дождаться какого-то элемента, когда другие ожидания не помогли. Увы, таким образом мы можем терять много времени при запуске теста.

Если поставить один слип - это ещё ничего. Вы потеряете, скажем, 4 секунды - не смертельно.
Но если вы используете слип в 150 тестах, время их выполнения увеличится заметно.
Нет смысла объяснять, почему это плохо.

Хотя команда sleep() есть и в Selenide, вышеупомянутые “умные ожидания” делают слипы почти ненужными для ожидания появления чего-то либо на странице.
Смотри следующие пункты.

2. Как дождаться окончания загрузки страницы?

Самый простой способ - выбрать какой-то элемент на странице, который редко меняется (скажем, заголовок), и использовать метод Selenide:

$(cssSelector).shouldBe(visible);

Selenide сначала попытается найти элемент, а потом проверить, что он видимый.
Если это не удалось за 4 секунды, вы можете сделать вывод, что страница не загрузилась.

Ещё вы можете выбрать какой-то элемент на предыдущей странице и дождаться, пока он исчезнет:

$(element).should(disappear);

Таким образом мы создаём двойную проверку, что мы перешли с одной страницы на другую. И это будет работать, даже если загрузка страницы занимает значительное время. Как видите, обошлись без всяких Thread.sleep().

3. Изменение состояния элемента

Иногда нам нужно проверить, что состояние элемента поменялось в результате действий пользователя.
Например, элемент может содержать текст, сигнализирующий об успешной или неуспешной загрузке файла.
Допустим, загрузка файла занимает какое-то время, потому что файл большой, или сервер должен запустить какую-то сложную обработку этого файла.

Обычно мы в тесте загружаем файл и проверяем состояние элемента (скажем, текст “файл загружен”).
Но как узнать, когда именно состояние элемента должно поменяться? Загрузка-то происходит не мгновенно.
В этой ситуации многие используют Thread.sleep().

А в Selenide у нас есть умный инструмент для “отложенной” проверки состояния элемента:

$(cssSelector).shouldHave(exactText(<expectedText>));

В этом случае Selenide сам дождётся, пока состояние элемента изменится, и в нём появится нужный текст.
Нам не нужно писать лишних строк для ожиданий, и мы можем быть уверены, что Selenide точно дождётся.

Что теперь?

Мы рассмотрели всего лишь несколько простых идей, как можно “ждать” с помощью Selenide.
В реальности ситуаций намного больше. И здорово, что теперь у нас есть хороший инструмент, позволяющий нам обходится без слипов и не терять драгоценное время.
Используйте умные инструменты и не теряйте время - время ценно. :)

Maciej Grymuza (figrym@gmail.com)

20.12.19