В очередной раз сталкнувшись с вопросом ораганизации юзеров в PageObject, решил поинтеросоваться мнением комунны о решении такой насущной для каждого задачи. Она настолько типична, что скорее всего уже где-то есть отдельный микро паттерн, тем не менее многие реализуют её по разному.
Итак - у нас есть N количество юзеров, каждый со своими ролями и своими личными данными.
Есть несолько окружений на которых эти юзеры могут быть задействованны. допустим, что на разыных окружениях связки логин\пароль у них разные.
Браузер мы открываем один раз, логинимся, потом прогоняем пачку тестов. Данные о юзере должны присутствовать уже на этапе @Before методов.
Как, с вашей точки зрения, можно оптимально организовать данные о пользователях, где инициализировать классы пользователей (если таковое нужно), как удобно модифицировать эти данные?
Т.е. пачка тестов должна запуститься последовательно с 1 юзером. Затем другая пачка тестов, опять-таки, последовательно с другим и т.п.?
В параллели тесты собираетесь запускать? Как много полей, помимо username / pass / role, еще собираетесь использовать на уровне юзера? Могут ли несколько тестов использовать 1 и тот же аккаунт одновременно?
Данные условия существенно усложняют модель, в тоже время не могу не согласится с их безусловной важностью.
Рассмотрим вариант где пачки с разными юзерами идут паралельно, допустим юзеры разделены по функциональным областям и не пересекаются.
Да, собираемся.
Часто используемых полей порядка 5 - 6.
Несколько тестов использовать один аккаунт конечно же могут, но тут нужно подумать на синхронизацией их действий. Помнится у Коли Алименкова был замечательный доклад в помощь организации подобных вещей.
Какой unit framework используете? Помимо юзеров, планируется ли поставлять еще какие-либо сущности в тест? Хотелось бы понимать, как вы на текущий момент работаете с данными.
Поставляются бизнесс объекты содержащие тестовые данные.
Хотелось бы отметить, что поставка юзеров в тест дело достаточно спорное, так как на процедуры релогина будет тратится время которое, при должной концепции, можно сохранить.
Т.е. вы хотите отделить юзера от модели? Вот тут как раз техническая реализация гораздо усложняется. Плюс ко всему, на поверхность вылазит более общая проблема - микс низкоуровневых составляющих с бизнес логикой. Вам подготовку юзеров придется выносить на уровень условного раннера, что не есть гуд.
Касательно технических деталей: без пулов тут не обойтись. Взятый из пула юзер при этом должен быть еще и привязан к потоку. Группы прав придется параметризовать посредством testng.xml. Причем, скорее всего вам нужно будет сразу обрабатывать весь xml, формируя пулы юзеров относительно групп прав. При этом, перед каждым тестом вам все так же придется в условном прекондишене доставать юзера из пула по параметру группы.
Это мы еще не затронули вопрос генерации / извлечения самих пользователей.
В моем понимании это даст прирост производительности. В приложении, для авторизации используется внешняя WebSSO система, логин в которую, к сожалению, не моментален.
С радостью рассмотрю варианты которые гуд.
Ну вот к примеру: распаралеливание начинается в сьютах на уровне тестов. В каждом тесте на упрвене testng.xml параметром передается роль юзера, которая аплаится к определенному списку тестовых классов.
В каждом из классов в Before идет вызов пула юзеров по полученной роли. инициализируется юзер и происходит логин.
Далее прогоняются тесты. На вскидку, проблемы с потоками должны решаться на уровне формирования сьютов и организации самого пула юзеров.
testomat.io управление авто тестами