elvis

 

 

a[class=\"gi-icon-caret-left2\"]:contains(Мои роли)

 

 

Как минимум "Мои роли" должны быть в кавычках

 

Но в любом случае были траблы с contains и css

 

Перепишите на Xpath

 

[contains(text(), 'Мои роли')]

 

Спасибо, проверил с xpath-заработало. Css и с кавычками не заработал. Очень жаль конечно, css больше по душе был.

 

Вы всегда можете проверить себя вбив локаторы в консоль браузера. $$("css локатор") или $x("//xpath локатор")

 

 

 

Это на самом деле не элемент, а проксиэлемент (этож PageFactory) и поиск по сути происходит при каждом обращении.

 

Я тоже раньше так считал, и не поверил своим глазам, когда повесил переинициализацию на элементы. 

Где собака зарыта и на какой глубине, я пока не знаю (возможно плацебо + время инициализации делают свое дело :) ).

 

 

 

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

Можно было проще обыграть:

- Жмем кнопку

- Т.к. это логаут смотрим, разлогинило нас или нет

Если не вышли: -  Чекаем контент на script (есть ли, загрузился ли)            

                           -  Жмем кнопку еще раз

 

и в loop если необходимо

 

А если у юзеров кнопка будет срабатывать всегда со 2й попытки? Тест ваш будет зелёный?

попробуй проверять document.readyState (гугл в помощь) или то, что функция определена

не отработали какие-то вещи на странице, нужно ждать, так как ExpectedConditions.elementToBeClickable - не панацея, увы

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

По поводу варианта elvis

по мне

 

ошибка expected [true] but found [false]

выглядит менее читаемо в отчете, чем

ошибка

не совсем понял о чём вы? Выглядеть оно будет не так.

ребят, ну что вы как маленькие. Читаем документацию 
 

можешь в ассерт вставить сообщение которое будет вываливаться при фейле. И в это сообщение можешь любую информацию о переменных вывести. Элементарные вещи спрашиваете.

"//a[@href='/welcome']" 

И не советую использовать полный путь xpath как вы это делаете. Добавится какой-нибудь элемент в промежутке и все локаторы слетят. Пользуйтесь атрибутами элементов для поиска.

с элементами у которых нет уникальных атрибутов обычно поступаю так - ищу какой-то уникальный якорь либо child элемента, либо parent относительно которого искомый элемент всегда имеет неизменное положение и составляю xpath отталкиваясь от этого. Если у самого элемента нет никаких опознавательных знаков, то уж у одного из parent'ов всяко будет.

ну и самый короткий вариант в данном случае 
(//h1)[1]

Было бы слишком просто. Чтобы научиться надо самому пощупать ручками, да ведь? В хроме нужно научиться использовать дебагер и ставить брейк поинты. Тогда список не будет скрываться и вы сможете прощупать его содержимое с помощью инспектора. Ну примерно так вот пощупайте:

https://dropmefiles.com/6nLC8

Ожидание всплывающего модального окна. А использовать ExpectedConditions не судьба? Зачем изобретать велосипед?

Как по мне так это лишняя информация. Подробное логирование может быть полезно для того, чтобы дебажить код, но в репорте зачем видеть это? Важно видеть прошёл тест или нет, а почему не прошёл, так это как правило видно из ошибки, которая выбрасывается TestNG.

assertTrue(driver.findElements(By.tagName("parsererror")).size() == 0);

или 

assertTrue(driver.findElements(By.tagName("parsererror")).size() != 0);

В зависимости от того, чего желаете дальше делать. У вас кстати не опечатка ли там ? 'parseerror' или 'parsererror' ?