будем использовать Robot Framework для автотестирования SAP. Чтобы не изобретать велосипед - есть ли где-то правила/принципы именования элементов интерфейса?
Задача у нас большая, тестов будет много, жизнь будет долгая, хочется обойти побольше граблей, не наступая…
В программировании есть несколько подходов/правил именования переменных, следуя которым код становится более читаемым/поддерживаемым. Есть ли что-то подобное для UI?
Робот позволяет именовать переменные по-русски (чем мы и ползуемся). Возникает вопрос: как “правильно” назвать элемент UI?
Например,
${номер договора} - хранит ID текстового поля на экране поиска договора страхования, в которое нужно вводить номер договора для его поиска.
Ряд вопросов:
иерархическое положение контрола: включать как-то в имя или нет?
тип контрола (текстовое поле): включать или нет?
к чему “привязываться” при именовании, к label (не для всех есть), к tooltip (аналогично) или к здравому смыслу?
Заранее благодарен за ответы - мы через какое-то время правила создадим (у нас достаточно большая команда и долгая жизнь, без правил получится бардак), но не хотелось бы совсем с нуля…
если использовать только робот для написания тестов то могу сказать что, да создать переменную и приствоить ей xpath/id/name или тому подобное, ету переменную можна использовать много раз и ето уменьшит код, Можеш переменную винести в *** Variables *** и использовать в дальшейшем в других тестах
в
*** Settings ***
Resource …/…/some/setup.txt
Правил нет, как сами придумаете, так и будет )
Эсли важно отделить именно контролы от данных, то можете ввести префиксы типа “кнопка_”, “поле_” и т.п. или просто “элемент_” или еще как угодно, что бы вам и команде было удобно.
П.С. называть переменные по русски, это бесчеловечно и чревато проблемаи при сохранении/вычитке в систему контроля версий или передедаче между юникс-виндовс и т.п. Бывали случаи с тем же гитхабом, когда кирилица превращалась в хрензнаетчто. Это так, чисто предупредить, понятно что вы учли все риски и поэтому используете.
Можете нагуглить бест практис по роботу. Использование кириллицы в роботе крайне не рекомендуется. Если проблемы с английским, то на крайний случай можно использовать транслит. Лично я именовал как то так: в верхнем регистре глобальные переменные в нижнем локальные и имена переменных в ресурсных файлах (что то вроде пейдж обджекта). Имена более чем в одно слово соединяю нижним подчеркиванием. По поводу именования веб элементов: имя страницы_имя элемента если не понятно что за элемент, можно дописывать сокращённое обозначение, например: btn, chkb, lst и т.д. Так же очень удобно размещать рядом с элементами кейворды которые более одного раза будут использовать в тестах, например для страницы гугла это будет кейворд search.
Про кириллицу услышал, погуглю, но пока отступать не хочу - это одно из явных преимуществ инструмента (возможность назвать “вещи” по-русски - я еще и сами keywords по-русски именую). У меня с английским все ровно, но у моих коллег - не у всех.
Согласитесь, такой тест привлекает
Открыть убыток
___Войти в сап
___Послать команду ${читать убыток}
___Записать текст в поле ${поле номер убытка} ${номер убытка}
___Нажать ентер
___${статус строка} = Считать статус строку
(подчеркивания вместо пробелов - не понял, как их тут ввести…)
Аналогично про отчет: там же тоже все эти слова выводятся, выглядит чарующе…
У меня робот - на убунте, тестовая система - на винде (естественно) через remote. Все работает ровно, пока никаких проблем с этим не нарыл. Сами авторы (автор) пишут - если все в UTF-8, то и славно (кстати, пока не было в UTF, то оно и не работало - не могло считать докстринги remote библиотеки…)
На крайняк можно будет все затранслитить программно (не бог весть какая сложность) когда и если упрусь. Но пока очень не хочется (см. выше).
Буду держать в курсе (про русский), если кто нароет что-то конкретное (что нужно проверить пока не стало мучительно поздно) - пишите, проверю (ибо сам больше всех заинтересован).
У нас в проекте был затык на русских кавычках (елочки которые) вроде. Все было в UTF-8. Ну а вообще, дело даже не в возможных проблемах, а в стандартах и общепринятых нормах. Тут все как в языках программирования, да есть такая вещь как 1С, но это скорее исключение, да и выглядит это ужасно. Русский язык не такой лаконичный.
P.S.: Решать то конечно вам, но лучше приучать себя и других за одно, к общепринятым стандартам в нашей области
я использую довольно длинные названия переменных-локаторов (порой состоящие из 3-4-5 слов, на английском правда, не на русском). Для меня цель этих названий - просматривая код тестов, сразу, и без лишних раздумий понимать:
какой именно элемент используется
где именно этот элемент находится
Мне без разницы, что это увеличивает длину строк/занимает больше места, главное не тратить лишнее время, не думать и не искать, что ***** тут используется и где оно ***** находится
вот несколько моих примеров:
reg_confirm_pass_field
buy_customer_form_country_drop_down_locator (можно конечно и сократить немного, вместо drop_down писать dd, к примеру, но уже как написал, так написал, не хочу тратить время на исправление этого)
tnm_products_overview_link_locator (здесь я наоборот использую сокращение tnm - top navigation menu)
а так, ysparrow правильно написал - как придумаешь, так и будет. Главное, чтобы вашей команде было удобно и понятно
testomat.io управление авто тестами
и где оно ***** находится 