XPath. Как выбрать невложенный элемент, следующий за искомым

программирование
#22

С чего б ему падать? <input id='cancel' type='button' onclick='cancel()' value='Войти'>

[quote=“alexkuzpro, post:21, topic:4490”]
Насчет не понравился id, я уже написал.
[/quote]Замените “не понравился” на “посчитал нужным”. Я никоим образом не могу расценивать такое его решение как некорректное. А на вашем проекте можно на это выписать баг в баг-трекере? Или баг на отсутствия id, или на его “рандомность”, или на “не уникальность”? Какой приоритет получают данные “дефекты”?

[quote=“alexkuzpro, post:21, topic:4490”]
А если програмер делает что ему угодно, как угодно и команда не общается между собой
[/quote]Угу. Представляю как 30 девов дергают двух автоматизаторов перед каждым изменением сорса, интересуясь не поломают ли они автотесты. У девов и своих юнит-тестов выше крыши - поэтому интеграционные их волнуют гораздо в меньшей степени.

#23

потому что поменялась логика, и последующие действия не выполнятся

Я его сам добавляю в проект если он мне нужен, а его нет. Если он не уникален, это косяк тех кто их менял. я его подправлю. айдишники не несут по сути никакой функциональной нагрузки на себе. Например если он не задан, он у нас генерируется автоматически. Подккоректировать или изменить его, не проблема, и это ни на что не повлияет (если он уникален). И теперь вопрос, зачем айдишники в таком случае кому-то трогать или менять кроме QA?

#24

Какая логика? Поменялись надписи на кнопках.

  <input id='login' onlick='login()' type='button' value='Отмена'>
driver.findElement(By.id("login")).click();

[quote=“alexkuzpro, post:23, topic:4490”]
Я его сам добавляю в проект если он мне нужен, а его нет.
[/quote] Это мегакруто когда тестеровщик может запилить что-нить в сорсы аппа, потом сбилдить в течении пары часов и задеплоить на сервер. На моем предыдущем проекте это мог делать быстро и качественно только один человек - build engineer. Вот только вам тогда надо называть себя не QA, а более конкретнее - SET со всеми вытекающими. И признать, что вы более software engineer, чем test engineer - отсюда и разница в мышлении.

#25

Дальнейшая логика теста не будет соответствовать и он упадет. И вообще PageObject ты не зря придумывали, что бы не писать везде driver.findElement

Я не знаю что такое SET, но в чем проблема? QA это обеспечение качества во всех можно так сказать смыслах. Да и кто должен билдить проэкты и деплоить на тест сервер? Програмисты? Админы? После каждой слитой фичи бегать и просить? Это только занимает время. Да и вообще разбивка на мануальщиков и автоматизаторов надеюсь скоро отойдет в прошлое. Обезьянки это конечно круто, но толку не много. А хороший QA должен досконально знать проект и обеспечивать качество не только после разработки, но и во время разработки. Поддерживать и расширять тесты, смотреть мануально и понимать немного в коде проекта, что бы более четко определить в чем ошибка и не задела она что то другое. Но это все имхо)

#26

SET - Software Engineers in Test. Попытка от гугла сделать гибрида - человека с мышлением тестера и навыками разработчика. Но даже у него это не очень хорошо получается - таких людей крайне и крайне мало.
Я вот вам уже четвертый пост элементарный пример на двух кнопках объясняю - все никак.

#27

Ну тут два варианта, или вы плохо объясняете или вы не правы)

Ну в целом я согласен, но тут все больше зависит не от людей, а от компании. Захочет она вырастить себе такие кадры или нет. И почему это у гугла плохо получается?)

#28

[quote=“alexkuzpro, post:27, topic:4490”]
И почему это у гугла плохо получается?)
[/quote]По факту - “Как тестируют в Google” Джеймс Уиттакер. А так как со стимулом, как с материальным, так и с духовным, у гугла все ок - то вариант только один.

Ок.

Было:

Сорс:

<input id='login' onlick='login()' type='button' value='Войти'>
<input id='cancel' onlick='cancel()' type='button' value='Отмена'>

Автотест:

driver.findElement(By.id("username")).sendKeys("username");
driver.findElement(By.id("password")).sendKeys("paswrd");
driver.findElement(By.id("login")).click();
verifyTextExists("Welcome");

Manual тест:

Enter user name in "User Name" text field
Enter user password in "Password" text field
Click "Войти" button.
Verify text "Welcome" exists

Запускаем…
Автотест: passed
Manual тест: passed

Вдруг (не важно как - полетели индексы, нарушилась целостность, нечаянный update, накосячили в биндингах, или просто работник, попавший под увольнение из-за нестабильной политико-экономической обстановке в стране, сделал пакость) стало:

Сорс:

<input id='login' onlick='login()' type='button' value='Отмена'>
<input id='cancel' onlick='cancel()' type='button' value='Войти'>

Запускаем…
Автотест: passed
Manual тест: failed

#29

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

Как вам такой пример. У вас 1000 тестов которые проверяют почти всю функциональность системы. Вы их запускаете и все падают из-за логина если бы была привязка к тексту в кнопке. полный проход тестов занимает прилично времени и зачастую тесты всей пачкой запускаются ночью. Допустим.

И второй вариант, у вас 1000 тестов из них 100 проверяют дизайны, тексты и тд, а остальные проверяют функциональность системы. Тесты запускаются, из них падает 20 тестов по причине неверного текста в кнопке, и 120 тестов падают потому что нашли серьезные баги.

В первом варианте вы по сути потеряете время и весь результат тестов
Второй вариант вы найдете кроме проблемы с текстом еще другие баги

К чему я это все. А к тому что каждый конкретный тест должен проверять какую - то конкретную вещь или функциональность(Даже если она довольно обширна, хотя в данном случае и это лучше подробить).

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

И еще, я искренни надеюсь что ваши тесты так не выглядят))

driver.findElement(By.id(“username”)).sendKeys(“username”);
driver.findElement(By.id(“password”)).sendKeys(“paswrd”);
driver.findElement(By.id(“login”)).click();
verifyTextExists(“Welcome”);

PageObject ты и создания классов сценарий позволяют минимизоровать дублирование кода, и разделять логику, реализацию и шаги выполнения. Что опять же потом очень легко исправлять в одном, максимум пару мест)

#30

Мне не жалко времени, что бы улучшить качество тестирования.

[quote=“alexkuzpro, post:29, topic:4490”]
Тесты запускаются, из них падает 20 тестов по причине неверного текста в кнопке
[/quote]А положив руку на сердце - вы часто проверяете текст, когда локейтите по id ради одного клика?
Для пользователя работающий функционал - это правильное поведение системы, при его действиях основанных на взаимодействии с тем, что он видит на экране. Поэтому оставшиеся 900 тестов я могу назвать юнит-тестами и они мало что говорят о качестве продукта.

И че вы к коду прицепились? Мне что, ради трех строк классы ваять нужно?

#31

Нет конечно, На основные элементы дизайна и тексты есть специально обученные тесты.

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

Как пример функциональности, ввод данных контрагента. Несколько шагов. Проверяются все возможные варианты валидации, переходы на следующие шаги, возвраты к предыдущим, корректность сохранения, отображения данных. Или редактирование информации о конрагенте с последующией проверкой изменения информации в смежных сущностях. Так вот каким боком эта функциональность имеет отношение к функциональности логина если для этого есть свой тест?

#32 
//*[contains(@id, "agentMenu:xxx")]/following-sibling::*//*[contains(@id, "agentMenu")]