Теория большого вейта
Тема ожиданий вызывает много обсуждений и споров.
Современные веб-сайты создают проблемы для написателей автотестов. Возникает много ситуаций, в которых стандартные методы 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