Повторное использование тестов для прогона

junit
java
webdriver
Теги: #<Tag:0x00007fedb8ac9768> #<Tag:0x00007fedb8ac9628> #<Tag:0x00007fedb8ac94c0>

(Jeyson X) #1

Всем привет.
Пытаюсь в который раз заниматься автоматизацией. Java + JUnit + WebDriver

Первый тест: установка необходимых прав для пользователя
Второй тест: заход в приложение
Третий тест: проверка доступного функционала согласно установленных прав
Четвертый тест: смена прав для пользователя

И вот проблема, мне нужно тоже самое проверить т.е. для пользователя с правами из теста 4 прогнать снова второй и третий тест.
Как это сделать?
Отдельный класс создавать и там снова повторять эти тесты ?


(Bohdan Harasym) #2

класс хелпер или в пейдж обдж… как кому угодно
метод: установка необходимых прав для пользователя
метод: заход в приложение
метод: проверка доступного функционала согласно установленных прав
метод: смена прав для пользователя

методы юзать в тестах как степы

все


(Dmytro Serdiuk) #3

According to your questions, the tests above are just steps in your tests. For instance, if you have 2 different user roles, you should implement two tests: test user role 1 and test user role 2. And, as @Bohdan_Harasym mentionede, your tests will have 3 steps:


(Oleksandr Khotemskyi) #4

Буквально соседний тред -

Или гуглите по запросам - DataProvider pattern , DataProvider for junit


(Roma Marinsky) #5

По сути у тебя это будет 1 кейс для проверки аутентификации роли пользователя.
Тебе нужны:

  1. Данные для теста: роль, доступный функционал
  2. Классы для страниц (авторизация, регистрация, страница с функиональными отличиями ролей)
  3. Класс по паттерну Action (некий юзер хелпер) - для установки роли пользователю через апи, через БД, через UI админа (через ui плозо такое делать, лучше апи или бд использовать). Установка роли по email или логин, или с другой возможностью приложения тебе. Можно и регистрацию бахнуть в нём, но не через UI, а с помощью api или бд
  4. С JUnit советую использовать библиотеку для провайдера данных https://github.com/Pragmatists/JUnitParams

(Дмитрий Мирошник) #6

Не очень хороший тест, поскольку при фейле, например, создания данного пользователя, все остальные тесты автоматом падают, соответственно, их информативность низка. Так необходимо делать только в случае необходимости проверить, что при изменении прав пользователя изменяются его уровень доступа к приложению.
Я бы сделал так:
1). Создаём user 1 с набором прав 1.
2). Создаём user 2 с набором прав 2.
3). Запускаем цикл тестов: зайти в приложение и проверить доступный функционал для user 1.
4). Аналогично для user 2.
В этом случае, фейл 1-го шага не повлияет на 2-й и 4-й шаги.
Ну и +, как уже посоветовали, DataProvider и PageObject, Factory.


(Roma Marinsky) #7

Не правда, все остальные тесты не повалятся если первый упадёт. Когда тест запускает на основе данных, то на каждый набор - это один тест. Если один тест на один набор упал, то остальные продолжат выполнться и в итоге у тебя будет 1 упавший тест и 4 успешныйм (к примеру)


(Jeyson X) #8

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


(Дмитрий Мирошник) #9

Когда тест запускает на основе данных, то на каждый набор - это один тест.

Это, конечно, прекрасно, но посмотрите на описание теста. Его слабое место - изменение данных. Таким образом, если то, к чему применимо изменение (в данном случае пользователь) не создастся - все 4 теста завалятся.


(Vatslau) #10

Я в таких случаях экспортирую что мне нужно в JSON
потом считываю когда мне нужно(пароли, токены и т.д.)
таким образом если даже будет фейл -смогу отдебажить без первых степов