Comments 8
Спасибо, любопытно. Концепция высокоуровневой команды Страница.ВыполнитьДействие, хоть и напрашивалась, но всё равно — прогресс.
А как правильно при таком подходе проверять переходы на другую страницу? Есть метод Page1.GoToPage2(). Как после этого проверить, что Page2 загрузилась так как мы ожидали?
Обычно, такой проверки на то, что Page2 загрузилась не требуется.
Например, в следующем коде:
При условии того, что Page2 не была загружена, строка ② просто упадёт. Если тесты снимают скриншот страницы автоматом при падении, то по нему будет видно, что страница 2 небыла загружена.
Второй вариант, это введение отдельного метода IsDisplayed, как в примере CreateNewAccountPage.cs для каждой страницы.
Смысл метода в том, что он определяет открыта ли страница по некоторому уникальному условию. В примере – это условия отображения контрола txtCaptcha на странице.
Для каждой страницы проверка на существование должно быть уникальным.
Например, в следующем коде:
var page1 = new Page1;
var page2 = page1.GoToPage2(); // ①
page2.DoSomeStuff(); // ②
При условии того, что Page2 не была загружена, строка ② просто упадёт. Если тесты снимают скриншот страницы автоматом при падении, то по нему будет видно, что страница 2 небыла загружена.
Второй вариант, это введение отдельного метода IsDisplayed, как в примере CreateNewAccountPage.cs для каждой страницы.
public override bool IsDisplayed()
{
return txtCaptcha.Displayed;
}
Смысл метода в том, что он определяет открыта ли страница по некоторому уникальному условию. В примере – это условия отображения контрола txtCaptcha на странице.
Для каждой страницы проверка на существование должно быть уникальным.
Проблема в том, что мы должны проверить наличие элемента через Page1, которого на Page1 быть не должно. То есть наша капча должна быть определена в Page2 (в Page1 она смысла не имеет).
Можно ли как-то дать понять что мы должны были оказаться на Page2 и вызвать myPage2.VerifyExpectedElementsAreDisplayed()?
Можно ли как-то дать понять что мы должны были оказаться на Page2 и вызвать myPage2.VerifyExpectedElementsAreDisplayed()?
Мне коротко объяснить всю эту штуку сложно, но я попробую.
В общем, если элемент txtCaptcha находится на физической странице Page 2, то и объявить его необходимо в классе Page2. Это вы верно говорите.
Для того, чтобы выяснить из метода Page1.GotoPage2(), отображается ли уже Page2 на экране или ещё нет, мы вызываем Page2.IsDisplayed().
В случае, если Page2.IsDisplayed() вернёт true – ничего делать не нужно. Страница Page2 уже открыта.
В случае false – нам необходимо проделать некоторые действия на странице Page1 для того, чтобы появилась Page2.
У меня есть доклад, в котором я менее скомканным образом рассказываю про эту тему.
Там же есть пример кода взаимодействия между страницами:
blog.zhariy.com/2013/02/atdays-pageobject.html
Посмотрите пожалуйста, если будет что-то не ясно, то я придумаю как продемонстрировать все наглядней.
В общем, если элемент txtCaptcha находится на физической странице Page 2, то и объявить его необходимо в классе Page2. Это вы верно говорите.
Для того, чтобы выяснить из метода Page1.GotoPage2(), отображается ли уже Page2 на экране или ещё нет, мы вызываем Page2.IsDisplayed().
В случае, если Page2.IsDisplayed() вернёт true – ничего делать не нужно. Страница Page2 уже открыта.
В случае false – нам необходимо проделать некоторые действия на странице Page1 для того, чтобы появилась Page2.
У меня есть доклад, в котором я менее скомканным образом рассказываю про эту тему.
Там же есть пример кода взаимодействия между страницами:
blog.zhariy.com/2013/02/atdays-pageobject.html
Посмотрите пожалуйста, если будет что-то не ясно, то я придумаю как продемонстрировать все наглядней.
Со временем, когда количество тестов будет расти, в случае использования бот-стиля, вы будете тратить все больше и больше времени на их поддержку.
Подтверждаю. Стоимость внесения изменений растет экспоненциально. За изменение некоторых тестов даже не хочется браться.
Встретился с задачей автоматизирования веб-приложения на C# + WebDriver. Всё хорошо, кроме ожиданий. Нашёл эту статью, полазил по исходникам и возник вопрос:
В Вашем примере используется System.Threading.Thread.Sleep(100); для реализации эксплицитных ожиданий.
Насколько я знаю, это яркий пример 'Worst Practices' работы с вебдрайвером. Почему тут используется именно Thread.Sleep()?
В Вашем примере используется System.Threading.Thread.Sleep(100); для реализации эксплицитных ожиданий.
Насколько я знаю, это яркий пример 'Worst Practices' работы с вебдрайвером. Почему тут используется именно Thread.Sleep()?
Сам Thread.Sleep ничем не плох и не хорош.
В моем коде, Thread.Sleep(100) используется для задержки на 100 миллисекунд в цикле, ожидания элемента для того, чтобы не напрягать браузер частыми запросами.
Т.е. в худшем случае, вы потеряете 1/10-ю секунды при ожидании одного элемента. Все относительно.
Для WebDriver тестов — это мало. Для юнит тестов и торговле на бирже ценных бумаг — это много.
Плохой практикой Thread.Sleep() становится, когда люди указывают константное время, например, 5 секунд для ожидания элемента.
Потом оказывается, что в IE, нужно подождать 10 секунд…
Тогда меняют Thread.Sleep(5000) на Thread.Sleep(10000)… и теперь тесты во всех браузерах работают со скоростью самого медленного.
Вот это — плохая практика.
В моем коде, Thread.Sleep(100) используется для задержки на 100 миллисекунд в цикле, ожидания элемента для того, чтобы не напрягать браузер частыми запросами.
Т.е. в худшем случае, вы потеряете 1/10-ю секунды при ожидании одного элемента. Все относительно.
Для WebDriver тестов — это мало. Для юнит тестов и торговле на бирже ценных бумаг — это много.
Плохой практикой Thread.Sleep() становится, когда люди указывают константное время, например, 5 секунд для ожидания элемента.
Потом оказывается, что в IE, нужно подождать 10 секунд…
Тогда меняют Thread.Sleep(5000) на Thread.Sleep(10000)… и теперь тесты во всех браузерах работают со скоростью самого медленного.
Вот это — плохая практика.
Sign up to leave a comment.
SWD.Starter: Быстрый старт автоматизации тестирования UI на C# + Selenium WebDriver + PageObjects