Быстрая проверка - есть элемент на странице или его нет

webdriver
, ,
#1

Возникла проблема и пока не знаю как её правильнее решить. Надеюсь на вашу помощь!

Ситуация: пользователь вводит логин и пароль, кликает “Вход”, после чего может оказаться на одной из двух страниц.

Вопрос: как правильно проверить на какой странице мы находимся?

1. Использую WebDriverWait, поэтому implicitlyWait = 0 мс,
2. Использую паттерн Page Object, где инициализация элементов через AjaxElementLocatorFactory

Какие уже были мысли:

  • Если проверять наличие элемента вот так:
    @FindBy(id = "pushOutMessage")
    private WebElement messageText;
    
    public boolean pageIsPresent() {
        return messageText.isDisplayed();
    }

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

  • Если проверять элемент с помощью “findElement”, то так как мои имплицитные ожидания = 0 мс и элемент не успеет загрузиться, то даже находясь на нужной странице метод вернет false
  • Создать еще один WebDriverWait с минимальным ожиданием (1-2 секунды) и проверять наличие элемента в таких ситуациях им. Не очень нравится этот вариант, надеюсь он не единственный и есть какой-то более элегантный способ

Подскажите - есть какие-то варианты решить эту ситуацию?

Явные и неявные ожидания - помогите разобраться
#2

Старницы рандомно открываются что ли?

#3

Нет. Если пользователь некорректно вышел в прошлый раз, то открывается страница подтверждения. Если нормально выходил - то страница личного кабинета.

#4

А если просто по заголовку страницы смотреть?

driver.getTitle()

2 лайка
#5

А кстати вариант, не подумал об этом, спасибо :relaxed:

Вот конкретно в данном случае да, наверное сработает. Но что делать если бы заголовок страницы не менялся?

#6

Я не совсем понимаю зачем Вам такая логика в тесте? Вы же ожидаете определенный результат после того как вводите логин\пароль, а не “случайное” попадание или в кабинет или на подтверждение.

Допустим в одном варианте вы создали условие что пользователь вышел “плохо”, значит делаем log in -> проверяем что мы на странице подтверждения.
В “хорошем” случае делаем log in и проверяем что попали в ЛК.

Или проблема в том что нельзя точно создать условия для хорошего и плохого входа?

1 лайк
#7

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

#8

использую кастомный велосипед аля HtmlElements :slight_smile:
у элементов есть метод bool IsPresent(bool withoutTimeout = false)
если надо “быстро” проверить, то передаю true
по дефолту - проверяю нормально.

если передаю true, то перед вызовом FindWebElement - удаляются все таймауты, после вызова (в finally) - возвращаются обратно

#9

Способ без таймаута рискованый - если элемент не успеет загрузится проверка будет ложной

#10

в бОльшинстве случаев где используется поиска без таймаутов, он там отрабатывает нормально.
тут надо смотреть конткретный случай и решать - имеет смысл там его использовать или нет (страница тупит, ajax ajax’ом погоняет, элемент грузится через 100500 секунд после прогрузки страницы ну и прочее :slight_smile: )

#11

Можно поискать общий элемент для двух страниц, но с разными атрибутами\текстом и проверять по этому признаку на какой странице в данный момент находимся.

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

1 лайк
#12

Очень интересная мысль, пока не знаю на сколько применима на практике, но довольно хитроумно!

#13

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

#14

имхо:
это должно быть разнесено в 2 отдельных теста
рандома и условий в тестах быть не должно

#15

Нет, такое не пройдет. Был ли пользователь залогинен - это хранится на сервере. Чистый профиль тут не поможет, все равно будет сообщение, что вы пытаетесь зайти туда где уже кто-то есть.

#16

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

Если вы имеете ввиду тест - зайти в кабинет, некорректно выйти, снова зайти, то вопрос не в этом, а в том что нужна проверка для корректной работы других тестов, которые могут попасть в ситуацию - предыдущий пользователь некорректно вышел. Сам тест на “появляется сообщение или нет” не особо требуется.

#17

Сессия должна быть частично привязана к кукам. Так что если вы стартанете браузер, который ничего не знает о вашей прошлой сессии, сервер должен сгенерировать новый токен. К тому же, сессии в пределах одной тачки не должны конфликтовать. Вы ведь не с другого компа логинетесь.

#18

Куки тут не при чем. Идея вот в чем - если вы с одного компа залогинились под одним пользователем, а с другого компа кто-то другой пытается залогиниться под этим же пользователем - у него будет сообщение о том что этот пользователь уже “занят”, но его все еще можно выкинуть. Так что свежий профиль тут никак не поможет.

#19

У вас каждый тест запускается на разных компах, или что? Если нет, то система не должна трактовать запуск в пределах одного и того же ПК, как сторонний. Так что если вы будете подменять профиль там же, где был запущен предыдущий тест, никаких сообщений быть не должно.

#20

Тест на одном компе.
В рамках новой сессии - именно так и трактует, т.е. при попытке войти появляется страница что уже кто-то вошел.
В рамках одной сессии - появляется совершенно другая страница (“Вы уже зарегистрированы в системе”).

Вот такая реальность :smile: