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

[AlexanderZvonov]

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

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

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

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

[ArtOfLife]

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

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

[AlexanderZvonov]

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

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

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

В параллели тесты собираетесь запускать?

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

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

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

Могут ли несколько тестов использовать 1 и тот же аккаунт одновременно?

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

[ArtOfLife]

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

[AlexanderZvonov]

Какой unit framework используете?

TestNG

Хотелось бы понимать, как вы на текущий момент работаете с данными

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

Помимо юзеров, планируется ли поставлять еще какие-либо сущности в тест?

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

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

[ArtOfLife]

Поставляются бизнесс объекты содержащие тестовые данные.
Хотелось бы отметить, что поставка юзеров в тест дело достаточно спорное

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

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

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

[AlexanderZvonov]

Т.е. вы хотите отделить юзера от модели?

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

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

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

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

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

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

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

[ArtOfLife]

В каждом из классов в Before идет вызов пула юзеров

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

инициализируется юзер и происходит логин.

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

[AlexanderZvonov]

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

BeforeClass либо BeforeTest

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

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

[ArtOfLife]

BeforeClass либо BeforeTest

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

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

[AlexanderZvonov]

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