SWD.Starter: Быстрый старт автоматизации тестирования UI на C# + Selenium WebDriver + PageObjects

[lozga]

Спасибо, любопытно. Концепция высокоуровневой команды Страница.ВыполнитьДействие, хоть и напрашивалась, но всё равно — прогресс.

[GraDea]

А как правильно при таком подходе проверять переходы на другую страницу? Есть метод Page1.GoToPage2(). Как после этого проверить, что Page2 загрузилась так как мы ожидали?

[Dmitry_Zhariy]

Обычно, такой проверки на то, что Page2 загрузилась не требуется.
Например, в следующем коде:

var page1 = new Page1;
var page2 = page1.GoToPage2(); // ①
page2.DoSomeStuff(); // ② 

При условии того, что Page2 не была загружена, строка ② просто упадёт. Если тесты снимают скриншот страницы автоматом при падении, то по нему будет видно, что страница 2 небыла загружена.

Второй вариант, это введение отдельного метода IsDisplayed, как в примере CreateNewAccountPage.cs для каждой страницы.

public override bool IsDisplayed()
{
    return txtCaptcha.Displayed;
}

Смысл метода в том, что он определяет открыта ли страница по некоторому уникальному условию. В примере – это условия отображения контрола txtCaptcha на странице.
Для каждой страницы проверка на существование должно быть уникальным.

[GraDea]

Проблема в том, что мы должны проверить наличие элемента через Page1, которого на Page1 быть не должно. То есть наша капча должна быть определена в Page2 (в Page1 она смысла не имеет).
Можно ли как-то дать понять что мы должны были оказаться на Page2 и вызвать myPage2.VerifyExpectedElementsAreDisplayed()?

[Dmitry_Zhariy]

Мне коротко объяснить всю эту штуку сложно, но я попробую.

В общем, если элемент txtCaptcha находится на физической странице Page 2, то и объявить его необходимо в классе Page2. Это вы верно говорите.

Для того, чтобы выяснить из метода Page1.GotoPage2(), отображается ли уже Page2 на экране или ещё нет, мы вызываем Page2.IsDisplayed().

В случае, если Page2.IsDisplayed() вернёт true – ничего делать не нужно. Страница Page2 уже открыта.
В случае false – нам необходимо проделать некоторые действия на странице Page1 для того, чтобы появилась Page2.

У меня есть доклад, в котором я менее скомканным образом рассказываю про эту тему.
Там же есть пример кода взаимодействия между страницами:

blog.zhariy.com/2013/02/atdays-pageobject.html

Посмотрите пожалуйста, если будет что-то не ясно, то я придумаю как продемонстрировать все наглядней.

[AdrenaLeen]

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

Подтверждаю. Стоимость внесения изменений растет экспоненциально. За изменение некоторых тестов даже не хочется браться.

[aecid]

Встретился с задачей автоматизирования веб-приложения на C# + WebDriver. Всё хорошо, кроме ожиданий. Нашёл эту статью, полазил по исходникам и возник вопрос:

В Вашем примере используется System.Threading.Thread.Sleep(100); для реализации эксплицитных ожиданий.

Насколько я знаю, это яркий пример 'Worst Practices' работы с вебдрайвером. Почему тут используется именно Thread.Sleep()?

[Dmitry_Zhariy]

Сам Thread.Sleep ничем не плох и не хорош.
В моем коде, Thread.Sleep(100) используется для задержки на 100 миллисекунд в цикле, ожидания элемента для того, чтобы не напрягать браузер частыми запросами.

Т.е. в худшем случае, вы потеряете 1/10-ю секунды при ожидании одного элемента. Все относительно.
Для WebDriver тестов — это мало. Для юнит тестов и торговле на бирже ценных бумаг — это много.

Плохой практикой Thread.Sleep() становится, когда люди указывают константное время, например, 5 секунд для ожидания элемента.
Потом оказывается, что в IE, нужно подождать 10 секунд…
Тогда меняют Thread.Sleep(5000) на Thread.Sleep(10000)… и теперь тесты во всех браузерах работают со скоростью самого медленного.

Вот это — плохая практика.