Если мне когда-нибудь попадётся проект, в котором все элементы будут иметь неизменяемые id, это будет, наверное, самым лучшим моментом в работе
При использовании локаторов в Selenium очень часто так и тянет завязаться на text (). Это просто, удобно, железно, а подчас без него по-другому не получается.
Однако, данный подход работает до тех пор, пока вы не столкнулись с задачей “у нас появился заграничный заказчик, протестируйте этот же сайт, локализованный на “language” язык”.
Если кто-то сталкивался с подобной задачей, то расскажите, как вы её решаете, либо, поделитесь, пожалуйста, теоретическим подходом.
Мне пока не приходилось иметь дело с подобной проблемой, но её решение хотелось бы иметь заранее, т.к. предвижу, что это вносит сильные изменения в архитектуру тестов.
Пока мне видится такое решение: локаторы с текстом занести в словарь и, в зависимости от языка, выбирать нужное значение переменной.
Решение очень простое. Пусть сайт имеет хоть тыщу локализаций, тесты мы гоняем с английской локализацией и ищем элементы по английскому тексту. Мы так делаем в проектах. Работает.
Тогда конкретно для этой фичи надо написать ровно один тест, который именно смену языка и проверит. Скажем, с английского на русский. А все остальные тесты так пусть и гоняются на английском.
Написал ты тест смены локализации. Тест пройден. А в 42 местах вместо нужного сербского языка всё равно вылез английский или ещё хуже — какой-нить undefined или NaN.
[quote=“DmitriyZverev, post:1, topic:3650”]
Если мне когда-нибудь попадётся проект, в котором все элементы будут иметь неизменяемые id, это будет, наверное, самым лучшим моментом в работе
[/quote]Хорошее заблуждение. Всему и вся дать ID нельзя, увы. Потому придумали отличный способ — xpath. Поиск по тексту имеет ряд минусов. Текст может измениться, текст может быть динамическим (комментарии, например).
Так я и спрашиваю: “как?”. Расскажите, как это сделать, покажите код.
@dzhariy как-то писал про FindElement, где можно передавать несколько локаторов. Можно, например, использовать этот способ. Но хочется чего-то более красивого для данного случая.
скорее “не работает”. Я понимаю, что данное тестирование находится, по-видимому, где-то близко к тестированию вёрстки, и его проще провести руками.
Но, если кто-то решил проблему, то пишите, делитесь опытом.
сталкивался, решал так:
мапингом элементов + xpath’ов в конфигах
локаторы выносим в конфиги/xml/etc, аля:
en_locators.xml
de_locators.xml
которые содержат значения
locatorname1 : xpath
locatorname2 : xpath
…
подгружаем карты локализации в зависимости от значения в конфиге тестового проекта
а в коде, в элементам привязываемся не напрямую через xpath, а через “locatorname”
т.е. из xml’ки получаем xpath, по имени locatorname
минус всего этого - поддерживать мапы не удобно =) в итоге отказались от затеи гонять автотесты на локализациях, и проверяем автотестами только англ версию сайта/продукта
А чем плохо использовать словарь? Мы так делали. Искали все элементы по xPath, а затем проверяли сам текст. Если по xPath уже никак не получалось, искали элемент используя значение из того же словаря.
Этот словарь можно создавать самому(так тоже приходилось делать). Был проект где мы использовали файлы локализации которыми пользуются девелоперы. Тогда при смене языка нам нужно было только подменить файлы, и прогнать заново все тесты.
testomat.io управление авто тестами
скорее “не работает”. Я понимаю, что данное тестирование находится, по-видимому, где-то близко к тестированию вёрстки, и его проще провести руками.