Тест падает, следующий тест в том же классе падает следом

программирование java
, , , , , , ,
#1

Всем привет!
В написании тестов применила шаблон Page object. Есть класс, от которого все тесты наследуются. В нем есть аннотации @BeforeClass и @AfterClass (открытие и закрытие браузера по умолчанию)
В классе тестов от 1 до N тестовых методов, классы разбиты логически по функционалу. Например, логин из разных точек в приложении. В начале теста сам логин, проверка загрузки нужной страницы, лог аут.
Проблема:
Если первый тест упал (пример теста условный, для примера), то второй тест в этом классе запускается из точки падения, соответственно падает на первом шаге навигации к следующей форме логина.
Как можно решить эту проблему, чтобы упавший тест не влиял на следующий?

#2

Видимо, логаут нужно делать не в самом тесте, а в методе @BeforeEach или @AfterEach. Тогда он будет выполняться в любом случае, даже если тест упал.

А вообще тема более обширная, тут есть много вариантов получше.

1 лайк
#3

Вот потому что:

Архитектуру строят таким образом чтобы каждый тест стартовал условно с нуля (или с какими-то преднастрйками, но сейчас не об этом). С текущим подходом я мог бы рекомендовать два способа, первый уже высказал @asolntsev ответом выше, а второй - Добавить @BeforeMethod (@BeforeEach, в зависимости от тестраннера) который будет чистить куки браузера и открывать новую страницу, например того-же логина.

1 лайк
#4

Можно поподробнее о других вариантах?
Если тест фэйлится, логаут не всегда просто осуществить, так как непонятно на каком шаге падает и как вызвать логаут с него

#5

Мне кажется, я такой подход пробовала, но что-то пошло не так. Завтра ещё раз попробую, отпишусь. Может ещё какие-то варианты? Или вернуть к модели 1 класс = 1 тест, а сгруппировать тесты по пакетам?

#6

Начиная с 38:27

И заодно:

  1. Boost you autotests with fast authorization | by Aliaksandr Rasolka | Medium
  2. Fast authorization. Level— local storage. | by Aliaksandr Rasolka | Medium
3 лайка
#7
  1. не надо использовать BaseTest класс для этой цели, потому что он пересоздается для каждого тест класса. для хранения переменной драйвера лучше использовать тест контекст
  2. не все методы авторизации используют куки, поэтому более универсальный способ это переиспользовать браузер контекст или просто не закрывать сам драйвер
  3. непонятен тест сценарий. зачем делать логаут в конце каждого теста?
1 лайк
#8

Может есть примеры с гита? Пока не очень представляю, как реализовать
Про п3 - это пример, не более того. Логика чуть другая, тест может упасть в специфическом месте, на дойдя до нужного, а следующий это не учитывает, к примеру

#9

Благодарю, ушла смотреть :slight_smile:

#10

2 - оч плохой совет. Потом получим странное поведение тестов в зависимости от элементов сессии, накопленных в предыдущих завершенных тестах. А ловить плавающие ошибки, спонтанно появляющиеся в зависимости от того, в каком порядке запускались тесты в мультипотоке… Бррр…

1 лайк