mike1999

А Вы попробовали выполнить этот пример? Получили StaleElementReferenceException? Причину выявили? Придумали, как доработать код, чтобы избежать появления этого исключения? Сравнили полученный результат повторно с тем примером, где используется PageFactory?

 

(P.S. Я не агитирую за использование PageFactory и сам его практически никогда не использую, просто пытаюсь показать, в чём разница между этими двумя примерами)

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

По сути всем новичками - в указанном примере PageObjectWithoutPageFactory -

При выполнении указанного примера разница не будет заметна - и там и там (при поправке на кнопку поиска) все будет работать без всяких исключений. Разница будет заметна только в том случае, если с момента создания объекта страницы элементы будут пересоздаваться - в случае без фактори изначально определенный вебэлемент (fieldSearch = driver.findElement(By.id("lst-ib"));) с момента создания до непосредственного вызова вполне может пропасть из дом (например будет перерисован) и вылезет исключение. Во втором случае поиск элемента на странице происходит при каждом обращении к элементу через объект страницы, т.е. если даже элемент был перерисован, он все-равно отыщется.

"тестирование подсчета типа треугольника"

Я вот в тестировании 8 лет, на текущей работе уже тест-лид, сам собеседовал не раз. Решил сменить компашку, до этого собеселования нигде не проходил. И что вы думаете - на первом же интервью мне выдают задачу (дословно):

"- Составьте пожалуйста список тестов, для функции, на входе которой три параметра, а на выходе треугольник"

повторяю - это была дословная  постановка задачи. И с умным видом он откинулся на спинку кресла.

Это мне предложил технарь из компании "Открытые технологии". ТЕХНАРЬ БЛ& !!! Я вот конкретно эту задачу не встречал, и догадаться что за параметры передаются в функцию не мог. Попробывал было задать наводящие вопросы, что мол за значения в параметрах? (ну там длины это или тройки координат в пространстве) на что был ответ - типа "...вы мне скажИте какие это параметры..." ... что за параметры, что за треугольник на выходе. попробуй догадайся.... Ну я ему совставил кейсы для троек координат в пространстве(отголоски текущей работы) ...

... к чему это я .. А да... товарищи собеседующие кандидатов, прежде чем тестить кандидата потрудитесь вникнуть в суть задачь. Оригинальная задача звучит так: "Составьте список тестов для функции, в которую передается три значения длин, а на выходе функция выдает - одно значение BOOLEAN - true, если существует треугольник со сторонами такой длины, и false если не существует".

В случае если функция до кучи определяет тип треугольника - половина ответов, что тут написана - полная бредятина, 50кейсов это заява от кого? Кто-нибудь вообще слышал об избыточности тестов? С таким подходом тестирование по стоимости будет в несколько раз дороже всего остального проекта + все как макаки уперлись в этот треугольник, никто даже не заикнулся про проверки максимальных значений, про проверку требований, явных, неявных, производительность... мы функцию проверяем, а не треугольник...

Опять же к чему это я... а да... на собеседовании постарайтесь не бросаться на составление максимального числа перестановок и конкретных значений. При любой задаче на составление тестов уточните непонятные моменты, составьте микро тест-план, составьте микро-список требований, разделите из на приоритетные и нет, постройте в голове маленькое оглавление для сценария - типа - Смок, функционал, производительность, юзабилити(+эргономика), безопасность, окружение...  и тд, все виды и подвиды, какие вспомните, далее по каждому пункту определите нужен он или нет. Далее наиболее критичные тесты. Не бойтесь записывать.

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

Как пример, периодически даем на проверку кандидату форму доступа путем ввода пятизначного цифрового пароля, для сенсорного терминала, и просим "на лету" протестировать и составить отчет.

Форма намеренно заторможена на нажание кнопки "0" - пауза секунд 5.

Правильный пароль известен.

На форме цифры, спецсимволы ,"Отмена", "Вход", "Язык", у тестера есть возможность задать правильный пятизначный пароль обычным апдейтом на рядом стоящем компе.

Все кидаются проверять и перебирать пароли.

Как результат :

Половина не замечают тормозов другая половина, замечает, матерится на тормоза, но в отчете не указывает.

Половина вводит только пятизначные значения.

Половина вводит только цифры.

95% не проверяют вход при пустом пароле и вход с пустым паролем о комбинациях(0/NULL) я уже не говорю.

95% не проверяют кнопку "Отмена".

95% не уточняют может ли пароль содержать спецсимволы с клавиатуры терминала.

Один человек за 3 года проверил смену языка.

Никто не проверяет добавление к правильному паролю других цифр и спецсимволов.

Никто не проверяет обрезанный с конца пароль.

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

Ох скока я понаписал...