Я согласен, что в некоторых случаях лучше использовать 1 драйвер, а не пересоздавать его с каждым тестом, но driver.get(URL); по моему мнению является частью той-же проблемы. Если мы тестируем сайт и у нас 1000 тестов на его функционал (большой, сложный сайт), и 99% тестов проходят под одним юзером - имеет ли смысл в каждом тесте делать "get(URL) + логин + очевидно где-то логаут"? Я думаю, что нет.
Но тогда интересно, как лучше реализовать логин, логаут и гетЮрл в @Before Class/Method/Suit при условии, что драйвер не пересоздается? Поведайте о своей/поделитесь чужими практиками, пожалуйста. Спасибо)
п.с. ну гетЮрл еще ясно, @BeforeMethod или класс в помощь. а логин и логаут? Обязательно ли запихивать в тело теста?
Т.е. выполнять все тесты в рамках одной сессии? Насколько это вообще реально для пользователей с разными правами, к примеру? Что будет если какой-то тест упадет на произвольном степе? Как следующий подхватит экзекьюшен в рендомной точке приложения?
Когда-то страдали подобным. После чего пришли к выводу, что оно того не стоит, ибо приходилось изобретать собственную “умную” навигацию, и тонну доп. пре/пост кондишенов. Не смотря на то, что многие кричат о доп. накладных расходах на открытие браузера, я лучше пожертвую парой лишних секунд, но буду спать спокойно с мыслью о том, что завтра мне не придется изобретать очередной велосипед для простого сценария.
У нас каждый тест начинается в с команды login(username). А эта команда реюзает вебдрайвер и проверяет, какой юзер был там залогинен до сих пор. Если тот же самый (а это так в большинстве случаев), продолжает использовать ту же сессию. Если другой, тогда делает logout+login. Очень просто, быстро и надёжно.
Тут очень многое depends on application. Когда у вас есть требование тестировать под разными юзерами / с разными правами, к тому же делать это в параллели на разных окружениях, то менеджить юзеров и их авторизацию не так то и просто, как кажется.
Плюс ко всему, чекать в login текущего юзера может быть не всегда возможным. Если предыдущий тест свалился с 404 или с 500й на весь экран, у вас неоткуда вычитать текущего юзера. Т.е. остальные тесты сваляться на этапе проверки, так? Отсюда вы наверняка начнете добавлять доп. логику, присутствует ли элемент. Если нет, то что делать? Прямой редирект на логин скрин? Допустим. А что если прямые редиректы по URL запрещены? Таких мелких нюансов может быть миллион. Я думаю идея понятна: тесты становятся зависимы от unexpected bugs / ограничений самой системы. С одной стороны, можно сказать, что это круто - ведь мы находим новые баги. С другой стороны, эти новые баги никак не связаны с тем workflow, который должен был пройти конкретный тест, но тем не менее являются блокерами. Хотя, пойди мы по “прямому маршруту”, этой проблемы бы может и не возникло. Как результат, мы начинаем лепить множество workarounds вместо того, чтобы начать execution с “чистого листа”.
Конечно все это очень условно, и многие наверняка бы позавидовали вашему приложению, если таких проблем у вас никогда не возникает. Но, к сожалению, фаза активного девелопмента в распределенных тимах, как правило, предполагает наличие уймы блокеров для автомейшена, которые фиксятся не так быстро, как хотелось бы. И если есть возможность пойти по прямому пути с пересозданием инстанса браузера, но минуя множество unexpected ситуаций, то я пожалуй пожертвовал бы этой парой несчастных секунд.
Я спрашиваю, потому что эта пара секунд на 900 тестах у меня выливается в много секунд)
Я согласен с тем, что придется париться лишний раз и это “-”. Да и человеку который первый раз на это смотрит - будет сразу понятно что и откуда. В общем мне просто интересно, это не значит, что обязательно так и сделаю. На крайний случай может кому-то другому пригодится.
Но если уже вопрос возник - я думал над тем, чтоб, как сказал @Andrii_Bahtiozin , сделать "@BeforeSuite
login() и @AfterSuite - logout(), но в этом случае тест может свалиться и придется перелогиниваться, для этого нужен еще будет @beforeMethod (у меня 1 тест = 1 класс = 1 метод) с проверкой логина и если юзер не залогинен (или залогинен другой юзер)- то перелогиниться.
если нам нужен другой юзер - тест нужно будет начинать с логаутСтарыйЮзер, ЛогинНужный юзер, что смотреться будет дико немного. а если про это забыть - то тесты будут проходить не под тем юзером. В обще можно будет запутаться.
В любом случае спасибо, интересно было почитать ваше мнение.
Еще проблема в том, что у меня в тестах нет ЛогАута в принципе (кроме там, где я его непосредственно тестирую), потому что система позволяет 1ним юзером логиниться в много сессий (не спрашивайте, не я придумал) и в общем логаут в таком случае не особо нужен. Так что если прикручивать WebDriverFactory - то мне придется либо в 900 тестов всунуть логаут, либо в @AfterMethod, либо думать.
Ну вообще, при таком объеме тестов предположу, что общий экзекьюшен тайм у вас в принципе немалый. И посему, проблему надо начинать решать не на этом уровне. Как насчет грида / параллельного экзекьюшена?
Касательно всего остального, в том то и проблема - слишком много нюансов возникает в процессе, что в последствии может привести к тому, что вы будете тратить очень много времени на workarounds.
Можете попробовать выше указанные предложения и оценить дальнейший импакт на весь тест девелопмент процесс. Я ведь сказал, что многое зависит от проекта. Может для вас как раз такая схема и будет работать.
testomat.io управление авто тестами