Организация пользователей в моделе PageObject

page-object
Теги: #<Tag:0x00007fedb7635220>

(Alexander Zvonov) #1

В очередной раз сталкнувшись с вопросом ораганизации юзеров в PageObject, решил поинтеросоваться мнением комунны о решении такой насущной для каждого задачи. Она настолько типична, что скорее всего уже где-то есть отдельный микро паттерн, тем не менее многие реализуют её по разному.

Итак - у нас есть N количество юзеров, каждый со своими ролями и своими личными данными.
Есть несолько окружений на которых эти юзеры могут быть задействованны. допустим, что на разыных окружениях связки логин\пароль у них разные.

Браузер мы открываем один раз, логинимся, потом прогоняем пачку тестов. Данные о юзере должны присутствовать уже на этапе @Before методов.

Как, с вашей точки зрения, можно оптимально организовать данные о пользователях, где инициализировать классы пользователей (если таковое нужно), как удобно модифицировать эти данные?


(Sergey Korol) #2

Т.е. пачка тестов должна запуститься последовательно с 1 юзером. Затем другая пачка тестов, опять-таки, последовательно с другим и т.п.?

В параллели тесты собираетесь запускать? Как много полей, помимо username / pass / role, еще собираетесь использовать на уровне юзера? Могут ли несколько тестов использовать 1 и тот же аккаунт одновременно?


(Alexander Zvonov) #3

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

Рассмотрим вариант где пачки с разными юзерами идут паралельно, допустим юзеры разделены по функциональным областям и не пересекаются.

Да, собираемся.

Часто используемых полей порядка 5 - 6.

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


(Sergey Korol) #4

Какой unit framework используете? Помимо юзеров, планируется ли поставлять еще какие-либо сущности в тест? Хотелось бы понимать, как вы на текущий момент работаете с данными.


(Alexander Zvonov) #5

TestNG

Используется DataProvider

Поставляются бизнесс объекты содержащие тестовые данные.

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


(Sergey Korol) #6

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

Касательно технических деталей: без пулов тут не обойтись. Взятый из пула юзер при этом должен быть еще и привязан к потоку. Группы прав придется параметризовать посредством testng.xml. Причем, скорее всего вам нужно будет сразу обрабатывать весь xml, формируя пулы юзеров относительно групп прав. При этом, перед каждым тестом вам все так же придется в условном прекондишене доставать юзера из пула по параметру группы.

Это мы еще не затронули вопрос генерации / извлечения самих пользователей.


(Alexander Zvonov) #7

В моем понимании это даст прирост производительности. В приложении, для авторизации используется внешняя WebSSO система, логин в которую, к сожалению, не моментален.

С радостью рассмотрю варианты которые гуд.

Ну вот к примеру: распаралеливание начинается в сьютах на уровне тестов. В каждом тесте на упрвене testng.xml параметром передается роль юзера, которая аплаится к определенному списку тестовых классов.

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

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


(Sergey Korol) #8

А в каком именно Before вы собираетесь доставать юзера из пула?

Если вы достаете юзера из пула, подразумевается, что он уже проинициализирован. Иначе что у вас тогда в пуле будет храниться?


(Alexander Zvonov) #9

BeforeClass либо BeforeTest

Верно. Юзера дожны быть проинициализированы и заброшены в пул на самой ранней стадии.


(Sergey Korol) #10

Зачем вам тогда это делать в каждом классе?

П.С. Так какие еще вопросы остались? Вроде все понятно и очевидно. Осталось только реализовать. :slight_smile:


(Alexander Zvonov) #11

Изначально вопрос стоял в ознакомлении с разными точками зрения по данной задаче.
Вот, свой вижен, с вашей помошью, я уже изложил. :slight_smile: