testomat.io управление авто тестамиДобрый день! Пишу автотесты на Java+JUnit+SeleniumWebDriver. Никак не получается запустить несколько тестов последовательно, т.е. чтобы после выполнения первого теста, драйвер уходил в следующий тест. Везде ругается на метод getDriver() should be void.
Добрый день!
Здесь Ванг нет, поэтому предоставляйте код и будем смотреть 
А если взять и поместить код всех тестов в один метод, выполняемый последовательно?
Получится оооочень большой метод
К сожалению там очень много кода( завтра выцеплю проблемный участок и выложу
Ну тут несколько комментариев
1)тесты по возможности должны быть независимые. То есть не стоит передавать драйвер от теста к тесту. Что будет, если у вас по какой-то причине просто в одном из тестов умер браузер?
2)ошибка с void - надо обязательно смотреть код, тут, какжется, просто какая-то у Вас ошибка
Но основной момент - это 1ый пункт. Делайте тесты независимыми.
1 лайк
Всем спасибо, кажется разобрался. Переделал вызов, сделал его последовательным. Т.е. драйвер передается теперь как метод из предыдущего теста.
Зря вы так… с этим можно в итоге получить много проблем в будущем.
Драйвер - он такой драйвер, он может просто умереть… и в итоге у вас будут ошибки, которых можно избежать просто сделав тесты независимыми и просто инициализировать драйвер в before и убивать в after.
А c помощью механизма Rule в junit - можно это вообще обернуть в рулу и подключать ее к тестовому классу.
1 лайк
То есть вы предлагаете создавать браузер для каждого метода? И сколько тогда у вас по времени длится сьют? Как раз в беформетод можно проверять драйвер и если он умер то инициализировать новый, а создавать столько медленных браузеров - непозволительная роскошь
1 лайк
браузер поднимается считанные секунды - это время несоизмеримо мало со временем решения проблем, которые вдруг возникнут из неоткуда.
Или у Вас какой-то особенно медленный браузер?
Именно секунды, а не секунду, то есть смело умножаем эти секунды на количество тестов и получаем общее замедление тестов. Проблемы из ниоткуда не возникнут если перед методом просто проверят драйвер на отклик
Я думаю, что проблемы, о которых шла речь при использовании 1 инстанса браузера, - это кеш / куки / падающие тесты, которые лочат прохождение остальным и т.п. @sidelnikovmike скорее говорил о чистоте эксперимента, которая нарушается переиспользованием 1 браузера. Тесты, ввиду своей прямолинейности, не умеют принимать решения о том, что делать в случае ошибок / как корректно приводить систему в исходное, пригодное для дальнейшего тестирования состояние и т.п. Некоторые рассказывают о том, что человек тестирует в 1 браузере, потому и тесты должны гоняться в 1 браузере. Но почему-то тут же забывают о том, что машина не умеет думать и видеть, как человек. А аргумент, что мол хорошо, что тесты упадут в случае возникновения одной из выше указанных проблем, - совсем ничтожен, если какой-то минорный баг в итоге зафейлит экзекьюшен всего suite. К тому же, приведение системы в исходное состояние после падения теста порой может занимать гораздо больше времени, нежели открытие нового браузера. Так что вопрос этот весьма и весьма спорный - какой подход в итоге окажется быстрее и эффективней.
2 лайка
Да, нельзя не согласиться с @ArtOfLife и его словами о машинном мышлении и о том, что у вас может быть множество проблем с умением приводить систему в какое-то, необходимое тесту состояние.
По личному опыту(и не только) скажу, что те секунды(пусть будет так), затрачиваемые на поднятие браузера ничтожны по сравнению со временем, которое обычно работают тесты, а судя по всему их у вас очень не мало.
Вообщем видимо тут можно вопрос закрывать - изначально я хотел просто дать совет, как сделать ваши тесты более независимыми и отказоустойчивыми. Но как делать в конкретной ситуации - решать вам.
Проблема в том, что тесты идут именно последовательно - т.е. сначала авторизация, потом на этой же странице - поиск, потом в результатах этого поиска выбор нужного элемента и т.д. То есть инициализировать браузер заново в каждом тесте - абсолютно не вариант.
Как-то помню видел очень хорошую лекцию от @asolntsev, где он упомянал по поводу грамотности тестирования страниц отдельно и различных состояний… Андрей, не помнишь, где у тебя такое проскакивало?
1 лайк
Спасибо!
Наверное, ты имеешь в виду доклад на CodeFest в Новосибирске: Экономически эффективный процесс тестирования
P.S. Если что, все нужны видео можно найти здесь: Видео · Andrei Solntsev
Ага, он самый. В свое время очень понравился.
1 лайк
В общем случае junit не подразумевает очередности, ответ на вопрос топика: нормальным образом никак. Варианты 1 метода в котором в нужной очереди будут вызыватьяс остальные не нормально, чуть больше чем необходимость в поочередном запуске тестов(жирным выделенно не нормальное).
Если нет возможности решить проблему правильно, тоесть реорганизовать тесты(например по советам А. Солнцева например, раз уж его упомянули и он тут ответил), то используйте testng (не очень хорошо к нему отношусь из-за того что он дает возможность закостылить проблемы архитектуры) и в аннотации тест передавайте параметр proirity (вроде, точно не помню)
ну или еще dependsOnMethod.
Junit уже как бы закладывает в себе, что тесты должны быть независимыми.