может это у вас тестируемое приложение так много потребляет? Как всё выглядит локально?

зачем изобретать велосипеды?        

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

это не есть ожидание

что-то у вас тут какое-то масло масленное. Зачем два раза инициализировать драйвер?

 

 

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

 

 

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

 

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

 

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

 

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

 

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

 

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

.

а приоритеты тестам в коде как назначаете?

 

Гугление не помогло

не верю :) копайте в сторону ExpectedConditions и ожидайте видимости элементов.

Molechka как сняла с языка.

возьмите любой веб-проект с гитхаба, установите локально и автоматизируйте до посинения

 

Самый простой способ - это selenide

http://selenide.org/quick-start.html

 

Там есть ссылки на примеры на гитхабе

 

селенид хорош, но для меня сейчас больше актуален селениум.

 

а поподробнее - чем вам голый селениум актуальнее удобной обёртки вокруг него же?

не проверял, но по идее должно работать
mvn -Dwebdriver.chrome.driver=/path/to/chromedriver clean test
 

Перед кликом на кнопку временно сделал вытаскивание в строку driver.getPageSource(); И там вся страница целиком (вместе со скриптом).

И, наверное, это логично. Ведь если элемент отрисован и кликабелен (что проверяется перед кликом), значит это уже идет этап отрисовки и код страницы загружен вместе с нужной функцией.

 

Простой слип в 1000мс перед кликом избавляет от проблемы. Значит чего-то не хватает секундой раньше, но так и не пойму чего. :)

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

Но я же теперь спать нормально не смогу, буду думать о вопросе "Почему? И как можно сделать красиво?"

Если это один тест, то можно сформулировать требование так - кнопка logout активна через N ms после того, как стала видимой. И требования к задержке согласовать с продакт оунером. Далее дрючить девов :D

 

 

 

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

 

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

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

 

 

 

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

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

- Жмем кнопку

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

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

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

 

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

 

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

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

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

даа, как всё запущено. Нельзя же так тыкаться, как слепой котёнок. Есть же гугл в конце концов, есть множество сайтов и онлайн курсов по программированию для тестировщиков. Когда задают вопрос "где можно скачать нормальный Selenium", остаётся только руками разводить.

Надо вообще для себя сначала уяснить основы программирования на Java. Почитать про maven или gradle для начала. Ну и много ещё чего. То, чем вы сейчас занимаетесь - пустая трата времени, если сразу не начнёте подходить к этому с умом.

"условие в нутрии" 

приведите больший кусок кода. элемент li там явно не один?

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

elvis, коллега, здесь речь идет о робастности теста, а не поиске бага)

Я и не писал о поиске бага. Я как раз о том, что 100% робастности не будет никогда, но автоматизатор должен позаботиться о том, чтобы проблемы можно было легко анализировать, и тогда эти вещи нивелируются.

Вы должны предоставить достаточно информации в отчёте, чтобы можно было понять баг это или ложное срабатываение. Для этого делаются скриншоты, пишутся логи, записываются скринкасты и тд и тп. На CI, если у вас всё по умному реализовано и каждый тест метод независим от другого, можно автоматически перезапускать упавший тест для проверки на "flakyness".

Немного не в тему, но такой функционал есть в gauge https://github.com/getgauge .  Там кроме сценариев и спецификаций (аналог feature) есть ещё понятие concept, который составляется из существующих шагов, хранится в отдельном файле и может быть указан как шаг в любом сценарии. Если есть желание попробовать что-то новое, то gauge неплохая альтернатива cucumber. http://getgauge.io/d...s/concepts.html

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

по мне

 

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

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

ошибка

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

 

ну вот человек говорит, что элемент невидим, а значит и sendKeys работать не будет, хоть какие локаторы там задавайте. Есть другие идеи?

 

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

 

это ещё бабушка надвое сказала. Мало информации