В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

QA — Автоматизация

5730 membersпожаловаться на группу
2020 May 22

А

Александр in QA — Автоматизация
Scherbakov Alexey
Вообще, есть хорошее правило- методы и локаторы держать в разных классах. И подключать по необходимости.
предлагаю гибкий подход
если локаторы нужны в классе где есть методы которые с ними работают - там, в этом классе им самое место в виде полей
если локаторы используются в разных классах, тогда они или выносятся на уровень выше в случае если эти классы наследуются, либо объявляются статическими и доступны вообще везде где они нужны
источник
00:04пожаловаться#1

S

Sergey Sergey in QA — Автоматизация
Сейчас это куча методов, но это в том числе это задел, так сказать. Если вам внезапно понадобиться что-то добавить в работу какого-то элемента, а у вас один универсальный метод на все, что вы будете делать? Например добавить доп логики или валидации или еще чего
источник
00:04пожаловаться#2

A

Anna in QA — Автоматизация
Sergey Sergey
Сейчас это куча методов, но это в том числе это задел, так сказать. Если вам внезапно понадобиться что-то добавить в работу какого-то элемента, а у вас один универсальный метод на все, что вы будете делать? Например добавить доп логики или валидации или еще чего
Ну метод не один, а несколько. Я просто добавлю новые локаторы, и теми же методами пройдусь по новой форме, передавая локаторы как параметр в метод
источник
00:05пожаловаться#3

S

Sergey Sergey in QA — Автоматизация
Вы пойдете в нужный метод и добавите то что вам нужно. Это не зааффектит ни другие элементы ни старые методы
источник
00:05пожаловаться#4

SA

Scherbakov Alexey in QA — Автоматизация
Александр
предлагаю гибкий подход
если локаторы нужны в классе где есть методы которые с ними работают - там, в этом классе им самое место в виде полей
если локаторы используются в разных классах, тогда они или выносятся на уровень выше в случае если эти классы наследуются, либо объявляются статическими и доступны вообще везде где они нужны
Имеет право на жизнь)) у меня это скорее вкусовощина)) в конце концов, каждый пишет код по-разному, даже в рамках одной команды, в которой определены гласные и негласные правила
источник
00:06пожаловаться#5

S

Sergey Sergey in QA — Автоматизация
тут сложно объяснить без кода, а также сложно понять какое решение придумали вы. Возможно, что у вас все будет работать годами и не придется потом все это переписывать. А возможно эти нюансы приведут к проблемам и большому рефакторингу
источник
00:06пожаловаться#6

А

Александр in QA — Автоматизация
Scherbakov Alexey
Имеет право на жизнь)) у меня это скорее вкусовощина)) в конце концов, каждый пишет код по-разному, даже в рамках одной команды, в которой определены гласные и негласные правила
лично мне он представляется наиболее удобным:
с одной стороны локаторы не мешаются своим наличием там где ими никто не пользуется
с другой то что должно быть доступно - всегда доступно
источник
00:07пожаловаться#7

А

Александр in QA — Автоматизация
но да. фломастеры они такие.
источник
00:07пожаловаться#8

AV

Alexei Vinogradov in QA — Автоматизация
Anna
Бредом называю то, что пишутся одинаковые методы для клика по кнопке или ввода данных в поле, и эти методы жёстко завязаны на локаторы. Вроде же как раз такой подход нарушает концепции ооп?
Можно пример? Как это одинаковые методы?
источник
00:07пожаловаться#9

S

Sergey Sergey in QA — Автоматизация
для того, чтобы понять зачем вам куча методов, найдите, например, доклады Семенченко Антона, он буквально на пальцах рассказывает про ООП и зачем нужны геттеры и сеттеры (публичные методы для доступа к приватным полям), а также, какие могут быть потенциальные проблемы без этого
источник
00:08пожаловаться#10

SA

Scherbakov Alexey in QA — Автоматизация
Anna
Ну метод не один, а несколько. Я просто добавлю новые локаторы, и теми же методами пройдусь по новой форме, передавая локаторы как параметр в метод
Все концепции ООП и не только вы МОЖЕТЕ использовать, но это совсем необязательно. Есть только случае в которых СТОИТ их придерживаться. Хотя это скорее про паттерны разработки. Если вам кажется удобным другой подход- делайте как нравится. В конце концов у вас появятся свои "паттерны" написания кода.
источник
00:09пожаловаться#11

S

Sergey Sergey in QA — Автоматизация
А также свой опыт)
источник
00:09пожаловаться#12

AV

Alexei Vinogradov in QA — Автоматизация
Anna
Ну хорошо, на примере у автора курса три метода на три кнопки. У меня на работе только на одной странице работы с клиентскими данными примерно 600 кнопок и полей ввода данных. Можно же с ума сойти, описывая методы для каждого из них)
Есть теория, что лучше понимаются абстракции не завязанные на "кликнул туда - кликнул сюда",  а на функциональные бизнес действия - "положил в корзину", "продолжил заполнение адреса" и тд.

Впрочем на практике я всякого повидал и уже не так уверен...
источник
00:11пожаловаться#13

S

Sergey Sergey in QA — Автоматизация
Кстати говоря, отдельные методы также привносят понимание при логировании и, например, описанию действий для того же аллюра
источник
00:12пожаловаться#14

А

Александр in QA — Автоматизация
Alexei Vinogradov
Есть теория, что лучше понимаются абстракции не завязанные на "кликнул туда - кликнул сюда",  а на функциональные бизнес действия - "положил в корзину", "продолжил заполнение адреса" и тд.

Впрочем на практике я всякого повидал и уже не так уверен...
а в чем сомнения?
явно лучше дробить одну большую задачу на много маленьких
внутри маленького метода клик это просто клик, и исходя из названия (назначения) метода который его содержит, причина его наличия там как правило вполне очевидная
разве нет?
источник
00:13пожаловаться#15

А

Александр in QA — Автоматизация
исключения возможны, но стоит ли принимать их в расчет когда их количество сводится к абсолютному минимуму?
источник
00:14пожаловаться#16

S

Sergey Sergey in QA — Автоматизация
Правильно. Вроде ведь абстракция завязанная на бизнесе, как правило просто слоем выше делается и общается с этими самыми page object
источник
00:14пожаловаться#17

AV

Alexei Vinogradov in QA — Автоматизация
Александр
а в чем сомнения?
явно лучше дробить одну большую задачу на много маленьких
внутри маленького метода клик это просто клик, и исходя из названия (назначения) метода который его содержит, причина его наличия там как правило вполне очевидная
разве нет?
Я снова вроде бы понял все слова, но не смог понять суть высказывания
источник
00:15пожаловаться#18

А

Александр in QA — Автоматизация
> Впрочем на практике я всякого повидал и уже не так уверен...
источник
00:15пожаловаться#19

А

Александр in QA — Автоматизация
а в чем сомнения?
источник
00:15пожаловаться#20