Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как запустить несколько тестов последовательно?

java
webdriver
junit
Теги: #<Tag:0x00007f7b613f3750> #<Tag:0x00007f7b613f35c0> #<Tag:0x00007f7b613f3390>

(Алик Гилиздинов) #1

Добрый день! Пишу автотесты на Java+JUnit+SeleniumWebDriver. Никак не получается запустить несколько тестов последовательно, т.е. чтобы после выполнения первого теста, драйвер уходил в следующий тест. Везде ругается на метод getDriver() should be void.


(You Rooock) #2

Добрый день!
Здесь Ванг нет, поэтому предоставляйте код и будем смотреть :slight_smile:


(Sewa Makhinya) #3

А если взять и поместить код всех тестов в один метод, выполняемый последовательно?


(Алик Гилиздинов) #4

Получится оооочень большой метод


(Алик Гилиздинов) #5

К сожалению там очень много кода( завтра выцеплю проблемный участок и выложу


(sidelnikovmike) #6

Ну тут несколько комментариев
1)тесты по возможности должны быть независимые. То есть не стоит передавать драйвер от теста к тесту. Что будет, если у вас по какой-то причине просто в одном из тестов умер браузер?
2)ошибка с void - надо обязательно смотреть код, тут, какжется, просто какая-то у Вас ошибка

Но основной момент - это 1ый пункт. Делайте тесты независимыми.


(Алик Гилиздинов) #7

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


(sidelnikovmike) #8

Зря вы так… с этим можно в итоге получить много проблем в будущем.
Драйвер - он такой драйвер, он может просто умереть… и в итоге у вас будут ошибки, которых можно избежать просто сделав тесты независимыми и просто инициализировать драйвер в before и убивать в after.
А c помощью механизма Rule в junit - можно это вообще обернуть в рулу и подключать ее к тестовому классу.


(Farof Well) #9

То есть вы предлагаете создавать браузер для каждого метода? И сколько тогда у вас по времени длится сьют? Как раз в беформетод можно проверять драйвер и если он умер то инициализировать новый, а создавать столько медленных браузеров - непозволительная роскошь


(sidelnikovmike) #10

браузер поднимается считанные секунды - это время несоизмеримо мало со временем решения проблем, которые вдруг возникнут из неоткуда.

Или у Вас какой-то особенно медленный браузер?


(Farof Well) #11

Именно секунды, а не секунду, то есть смело умножаем эти секунды на количество тестов и получаем общее замедление тестов. Проблемы из ниоткуда не возникнут если перед методом просто проверят драйвер на отклик


(Sergey Korol) #12

Я думаю, что проблемы, о которых шла речь при использовании 1 инстанса браузера, - это кеш / куки / падающие тесты, которые лочат прохождение остальным и т.п. @sidelnikovmike скорее говорил о чистоте эксперимента, которая нарушается переиспользованием 1 браузера. Тесты, ввиду своей прямолинейности, не умеют принимать решения о том, что делать в случае ошибок / как корректно приводить систему в исходное, пригодное для дальнейшего тестирования состояние и т.п. Некоторые рассказывают о том, что человек тестирует в 1 браузере, потому и тесты должны гоняться в 1 браузере. Но почему-то тут же забывают о том, что машина не умеет думать и видеть, как человек. А аргумент, что мол хорошо, что тесты упадут в случае возникновения одной из выше указанных проблем, - совсем ничтожен, если какой-то минорный баг в итоге зафейлит экзекьюшен всего suite. К тому же, приведение системы в исходное состояние после падения теста порой может занимать гораздо больше времени, нежели открытие нового браузера. Так что вопрос этот весьма и весьма спорный - какой подход в итоге окажется быстрее и эффективней.


(sidelnikovmike) #13

Да, нельзя не согласиться с @ArtOfLife и его словами о машинном мышлении и о том, что у вас может быть множество проблем с умением приводить систему в какое-то, необходимое тесту состояние.
По личному опыту(и не только) скажу, что те секунды(пусть будет так), затрачиваемые на поднятие браузера ничтожны по сравнению со временем, которое обычно работают тесты, а судя по всему их у вас очень не мало.
Вообщем видимо тут можно вопрос закрывать - изначально я хотел просто дать совет, как сделать ваши тесты более независимыми и отказоустойчивыми. Но как делать в конкретной ситуации - решать вам.


(Алик Гилиздинов) #14

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


(sidelnikovmike) #15

Как-то помню видел очень хорошую лекцию от @asolntsev, где он упомянал по поводу грамотности тестирования страниц отдельно и различных состояний… Андрей, не помнишь, где у тебя такое проскакивало?


(asolntsev) #16

Спасибо!
Наверное, ты имеешь в виду доклад на CodeFest в Новосибирске: http://2015.codefest.ru/lecture/990

P.S. Если что, все нужны видео можно найти здесь: http://asolntsev.github.io/ru/video/


(sidelnikovmike) #17

Ага, он самый. В свое время очень понравился.


(Ренат Исин) #18

В общем случае junit не подразумевает очередности, ответ на вопрос топика: нормальным образом никак. Варианты 1 метода в котором в нужной очереди будут вызыватьяс остальные не нормально, чуть больше чем необходимость в поочередном запуске тестов(жирным выделенно не нормальное).

Если нет возможности решить проблему правильно, тоесть реорганизовать тесты(например по советам А. Солнцева например, раз уж его упомянули и он тут ответил), то используйте testng (не очень хорошо к нему отношусь из-за того что он дает возможность закостылить проблемы архитектуры) и в аннотации тест передавайте параметр proirity (вроде, точно не помню)


(sidelnikovmike) #19

ну или еще dependsOnMethod.
Junit уже как бы закладывает в себе, что тесты должны быть независимыми.