Профит использования класса Page Factory

webdriver
, ,
#1

Доброй ночи, коллеги

Подскажите, какой вообще смысл использования Page Factory при проектировании тестового фреймворка, если спокойно можно пользоваться классом By для описания элементов страницы и по мере необходимости передавать их в методы класса пейджа.

Вот я о чем. Есть какой-то базовый класс

image
image967×485 18.5 KB

После этого есть класс пейджа логина, у которого элементы описаны как

image
image950×372 17.4 KB

Ну а уже непосредственно в тесте создается ссылка на объект типа LoginPage и производится авторизация…

Какой профит в данном случае я бы получил, если бы описывал элементы как
@FindBy
WebElement element;
…
Или же в чем плох такой подход ?

2 лайка
#2

Выскажу свое мнение, сразу скажу, за свои 3,5 года опыта я всегда работал только с Page Factory / Page Objects и BDD, потому не могу сказать о преймуществах других методов.

  1. Все веб элементы расположены в соответствующих классах и ясно, где что.
  2. Нету лишних элементов, отдельно от веб элементов (By элементов).
  3. Нету дополнительных врапперов для простых методов типа click(), sendKeys().

Думаю, есть и другие преймущества, которые я не могу сходу назвать.

#3
  1. Ничего не мешает хранить By или даже String локаторы в 1 месте
  2. Не всегда это хорошо, возьмём даже что у вас есть одинаковый локтор для разных кнопок, только текст внутри кнопки меняется. Значит нужно создавать кучу лишних елментов вместо обычного String.format
  3. Враепры сделаны для удобства или расширения функционала, инчего не мешает использовать стандартные селениумовские
1 лайк
#4

Спасибо за ответ. Как по мне, то это не совсем преимущества

Так с Ву точно так же. Все локаторы расположены в соответствующих классах. Из названия локатора понятно, какой элемент страницы он описывает.

Здесь в свою очередь нету лишних элементов типа WebElement, а также нету аннотаций @FindBy.

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

1 лайк
#5

Спасибо за ответ :wink:

Не до конца понял. Если не трудно киньте примерчик.

#6 
private final String locator = //*[@name=%s]

public void clickButton(String buttonName){
findElement(By.xpath(format(locator, buttonName)));
}
#7

На мой взгляд, эти врапперы и такого типа методы лишь усложняют фреймворк. Человеку со стороны, или просто новому человеку, который будет обслуживать / дописывать тесты может быть сложно понять, что происходит и потребуется больше времени, чтобы разобраться.

#8

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

#9

Да вот только вместо 15 локаторов я напишу 1. А у нас было такое что и 90 локаторов нужно было бы писать. А враперы это удобство. Перед тем же кликом делать скрол к элементу, после ввода текста, взять тект из поля куда ввели и написать его в лог, сделать метод вроде isElementPresent на проверку существования элемента или isDisplayed который не будет падать если елемента нет в ДОМе, ну или сделать тот же findWithCondition в который передать локатор и кондишен елемента который мы дожидаемся (прим. clickable, visible, etc…) уйма вариантов удобных и полезных враперов

1 лайк
#10

Вот и я о том же. Кроме этого, на враппер легко навесить аннотацию @Step которой передать ({by}, {keys}). В отчет аллюр будут записываться уже значения переменных.

Я делаю для себя вывод, что использования Page Factory бесполезно, кроме приведенного вами кейса. Но т.к. кейс не такой уж и частый, то зачем он надо :slight_smile:

#11

Твой подход охеренный. Так и делай. Не нужны никакие PageFactory.

3 лайка