M
тобишь если у вас страница ... форма из 100500 полей то для каждого поля будет свой метод?
Если это автотест интерфейса, то скорее всего все поля проверять не нужно?
Size: a a a
2020 August 08
MK
привет! а какую практику посоветуешь изучать молодым специалистам? если отказаться от геттеров. Например для Page Object
Геттеры? Как ещё вы хотите значение обьекта получать лол
M
Геттеры? Как ещё вы хотите значение обьекта получать лол
речь про Page object approach
MK
речь про Page object approach
И? Геттеры нарушают по ваше?
MK
Если назвать геттер иначе - он геттером быть не перестанет
M
Если назвать геттер иначе - он геттером быть не перестанет
метод для работы с элементами конкретной страницы - тоже геттер?
AP
метод для работы с элементами конкретной страницы - тоже геттер?
к примеру у вас поле ввода в пейдже.... в одной ситуации вы хотите сделать над ним проверку в другой действие. это как миниум 3 метода... а что если таких полей 10 в какой-нибудь форме регистрации
AS
Если в классе есть приватное поле, для которого есть публичные геттер и сеттер (неважно, написанные или сгенерированный ломбоком), то это абсолютно ничем не лучше, чем тупо публичное поле.
M
к примеру у вас поле ввода в пейдже.... в одной ситуации вы хотите сделать над ним проверку в другой действие. это как миниум 3 метода... а что если таких полей 10 в какой-нибудь форме регистрации
ну а в чём проблема большого количества методов?
AS
(есть байка, что наличие геттера/сеттера якобы позволит в будущем легче менять это поле, но это premature optimization в чистом виде)
AP
Andrei Solntsev
(есть байка, что наличие геттера/сеттера якобы позволит в будущем легче менять это поле, но это premature optimization в чистом виде)
я согласен =) так а практика то какая? особенно для тех кто только изучает java и автоматизацию... оставить все паблик и не париться... или же писать под каждое метод?
AS
Это уже зависит от вас, вашего проекта и т.д. тут нет универсального ответа.
AS
Главное - не усложнять без необходимости, не писать лишнего и т.д.
AP
Andrei Solntsev
(есть байка, что наличие геттера/сеттера якобы позволит в будущем легче менять это поле, но это premature optimization в чистом виде)
если хочется и локаторы отделить от теста... и сохранить гибкость selenide... для того чтобы делать множественные проверки
M
я согласен =) так а практика то какая? особенно для тех кто только изучает java и автоматизацию... оставить все паблик и не париться... или же писать под каждое метод?
писать по мере необходимости тестов
AP
писать по мере необходимости тестов
ну пример... вы хотите что-то ввести в поле... зачем для этого метод? почему не просто обратиться к элементу и сделать value/sendKeys ?
AP
ведь вы сразу гибко можете проверить что элемент в фокусе например.... а так у нас получается что мы эти методы городим в PageObject и они могут быть "одноразовые"
B
Скажу по секрету, элементы (они же локаторы, селекторы) не должны хранить свой статус. То есть они могут быть вполне статичными и публичными. И им не нужны геттеры и тем более сеттеры.
AP
Скажу по секрету, элементы (они же локаторы, селекторы) не должны хранить свой статус. То есть они могут быть вполне статичными и публичными. И им не нужны геттеры и тем более сеттеры.
я это все понимаю =) ну тобишь в PageObject мы можем все поля сделать публичными финальными статичными и в тестах к ним обращаться напрямую?
B
Естественно