Борьба с интерфейсом в UI-тестировании

Первая проблема была озвучена здесь: Борьба со сложностью кода UI-тестов

Вторая проблема возникает при взаимодействии кода теста с элементами интерфейса. Именно изменения элементов интерфейса серьезно влияют на работу UI-тестов. От того как реализовано взаимодействие кода теста с интерфейсом зависит насколько "хрупким" будет тест и как много потребуется изменений кода при изменении одного элемента интерфейса.

Например, недавно в типовой БП3 в форме списка спр. Контрагенты изменилось название колонки "Наименование" на "Наименование в программе". В результате упали все тесты, которые пытались найти элемент спр. Контрагенты по наименованию. Таких упавших тестов было много, т.к. этот справочник используется в большом количестве документов. От того насколько правильно спроектированы тесты зависит скорость и трудозатраты на восстановление системы автотестирования после подобных изменений. Если код выбора элемента описан в каждом сценарии, то править придется каждый сценарий. Если же код выбора локализован в процедуре, а сценарии его вызывают, то исправление займет минимум времени.

Для решения второй проблемы есть стандартный подход - отделение кода шагов тестового сценария от кода взаимодействия с интерфейсом, используя паттерны Page Object или Page Element. Одним из положительных побочных эффектов паттернов является снижение дублирование кода. Отрицательным эффектом является усложнение кодовой базы за счет увеличения уровней вложенности кода. Однако бездумное использование паттерна может привести к созданию суперпроцедур со сложнейшим кодом, которая содержит условия и пытается обработать все возможные варианты.

Например, документ БП3 "Списание с расчетного счета" имеет около 20 видов операций, которые значительно влияют на состав элементов формы документа. Кроме этого есть опция "Редактировать платежи в списке", которая "включает" отображение на форме табличной части. Таким образом процедура, описывающая форму документа, будет содержать больше десяти условий по каждому виду операций. Внутри этих условий будут еще условия и циклы, обрабатывающие строки табличной части. В данном случае паттерн Page Object нужно использовать осторожно.

Некоторые изменения можно предусмотреть. Как правило изменяется текст заголовков элементов формы или заголовок самой формы, т.е. то что видно пользователю. При этом практически не изменяются имена элементов формы. Поэтому в коде нужно использовать имена элементов управления, а не текст заголовка.

В тех случаях кода невозможно использовать имени элемента, нужно вынести текст заголовка в процедуру и вызывать ее из сценария. Также можно воспользоваться паттерном Page Element и вынести весь код обработки поиска нужного элемента в списке в отдельную процедуру, которая будет позиционироваться на нужной строке списка и заполнять элемент. Это решит проблему с поиском строки в списке где метод ПерейтиКСтроке может использовать только текст заголовка.

Для документа "Списание с расчетного счета" паттерн Page Object можно применить так: вынести код работы с формой в отдельные процедуры, сгруппировав по видам операций с одинаковым составом реквизитов. Получиться несколько процедур, они будут линейными и дублирования практически не будет, т.к. состав элементов формы будет различен.