Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Правила именования переменных, хранящих ID элементов интерфейса

robot-framework
Теги: #<Tag:0x00007f7b704e64f0>

(Michael Korolev) #1

Коллеги,

будем использовать Robot Framework для автотестирования SAP. Чтобы не изобретать велосипед - есть ли где-то правила/принципы именования элементов интерфейса?

Задача у нас большая, тестов будет много, жизнь будет долгая, хочется обойти побольше граблей, не наступая…

В программировании есть несколько подходов/правил именования переменных, следуя которым код становится более читаемым/поддерживаемым. Есть ли что-то подобное для UI?

Робот позволяет именовать переменные по-русски (чем мы и ползуемся). Возникает вопрос: как “правильно” назвать элемент UI?

Например,

${номер договора} - хранит ID текстового поля на экране поиска договора страхования, в которое нужно вводить номер договора для его поиска.

Ряд вопросов:

  • иерархическое положение контрола: включать как-то в имя или нет?
  • тип контрола (текстовое поле): включать или нет?
  • к чему “привязываться” при именовании, к label (не для всех есть), к tooltip (аналогично) или к здравому смыслу?

Заранее благодарен за ответы - мы через какое-то время правила создадим (у нас достаточно большая команда и долгая жизнь, без правил получится бардак), но не хотелось бы совсем с нуля…


(Yaroslav Boiko / Enapps) #2

если использовать только робот для написания тестов то могу сказать что, да создать переменную и приствоить ей xpath/id/name или тому подобное, ету переменную можна использовать много раз и ето уменьшит код, Можеш переменную винести в *** Variables *** и использовать в дальшейшем в других тестах
в
*** Settings ***
Resource …/…/some/setup.txt


(Michael Korolev) #3

Ярослав, я знаю, что такое робот и что такое “его” переменные. Вопрос был про правила их именования…


(Yaroslav Boiko / Enapps) #4

их ето кого?


(Yaroslav Pernerovskyy) #5

Правил нет, как сами придумаете, так и будет )
Эсли важно отделить именно контролы от данных, то можете ввести префиксы типа “кнопка_”, “поле_” и т.п. или просто “элемент_” или еще как угодно, что бы вам и команде было удобно.

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


(rmerkushin) #6

Можете нагуглить бест практис по роботу. Использование кириллицы в роботе крайне не рекомендуется. Если проблемы с английским, то на крайний случай можно использовать транслит. Лично я именовал как то так: в верхнем регистре глобальные переменные в нижнем локальные и имена переменных в ресурсных файлах (что то вроде пейдж обджекта). Имена более чем в одно слово соединяю нижним подчеркиванием. По поводу именования веб элементов: имя страницы_имя элемента если не понятно что за элемент, можно дописывать сокращённое обозначение, например: btn, chkb, lst и т.д. Так же очень удобно размещать рядом с элементами кейворды которые более одного раза будут использовать в тестах, например для страницы гугла это будет кейворд search.


(Michael Korolev) #7

Про кириллицу услышал, погуглю, но пока отступать не хочу - это одно из явных преимуществ инструмента (возможность назвать “вещи” по-русски - я еще и сами keywords по-русски именую). У меня с английским все ровно, но у моих коллег - не у всех.

Согласитесь, такой тест привлекает

Открыть убыток
___Войти в сап
___Послать команду ${читать убыток}
___Записать текст в поле ${поле номер убытка} ${номер убытка}
___Нажать ентер
___${статус строка} = Считать статус строку

(подчеркивания вместо пробелов - не понял, как их тут ввести…)

Аналогично про отчет: там же тоже все эти слова выводятся, выглядит чарующе…

У меня робот - на убунте, тестовая система - на винде (естественно) через remote. Все работает ровно, пока никаких проблем с этим не нарыл. Сами авторы (автор) пишут - если все в UTF-8, то и славно (кстати, пока не было в UTF, то оно и не работало - не могло считать докстринги remote библиотеки…)

На крайняк можно будет все затранслитить программно (не бог весть какая сложность) когда и если упрусь. Но пока очень не хочется (см. выше).

Буду держать в курсе (про русский), если кто нароет что-то конкретное (что нужно проверить пока не стало мучительно поздно) - пишите, проверю (ибо сам больше всех заинтересован).

Всем спасибо!


(rmerkushin) #8

У нас в проекте был затык на русских кавычках (елочки которые) вроде. Все было в UTF-8. Ну а вообще, дело даже не в возможных проблемах, а в стандартах и общепринятых нормах. Тут все как в языках программирования, да есть такая вещь как 1С, но это скорее исключение, да и выглядит это ужасно. Русский язык не такой лаконичный.
P.S.: Решать то конечно вам, но лучше приучать себя и других за одно, к общепринятым стандартам в нашей области :slight_smile:


(Michael Korolev) #9

Нормы придумывают люди. Я программирую с 1980 года, нашу область знаю хорошо - что ужасного кто увидел в вышеприведенном примере теста???

Кто сказал, что общепринятый стандарт - писать тестовые сценарии на английском языке??? Это чем удобнее русского?

out-of-the-box-thinking - это неплохо: когда-то и интернет был чем-то непонятным (я это еще застал).

Не убедили.

Удачи всем.


(Necrosium) #10

я использую довольно длинные названия переменных-локаторов (порой состоящие из 3-4-5 слов, на английском правда, не на русском). Для меня цель этих названий - просматривая код тестов, сразу, и без лишних раздумий понимать:

  1. какой именно элемент используется
  2. где именно этот элемент находится
    Мне без разницы, что это увеличивает длину строк/занимает больше места, главное не тратить лишнее время, не думать и не искать, что ***** тут используется :dizzy_face: и где оно ***** находится :smile:
    вот несколько моих примеров:
    reg_confirm_pass_field
    buy_customer_form_country_drop_down_locator (можно конечно и сократить немного, вместо drop_down писать dd, к примеру, но уже как написал, так написал, не хочу тратить время на исправление этого)
    tnm_products_overview_link_locator (здесь я наоборот использую сокращение tnm - top navigation menu)

а так, ysparrow правильно написал - как придумаешь, так и будет. Главное, чтобы вашей команде было удобно и понятно :slight_smile: