Разработка UI-тестов через запись действий пользователя. Часть 2.

Продолжаем эксперимент начатый в предыдущей заметке. Подключаем к проблеме технического специалиста и пробуем довести начатое до конца.

Начнем анализ с второй ошибки. Содержание ошибки указывает на следующую строку кода:

ТестовоеПриложение.НайтиОбъект(Тип("ТестируемоеОкноКлиентскогоПриложения"), "Требование-накладная КП00000004 от 30.03.2021 15:34:34", , 30);

Для исполнения UI-теста необходимо найти нужную форму чтобы выполнить действия. Поиск выполняется по заголовку формы. В нашем случае он содержит номер и дату документа, который использовался при записи действий пользователя. Но сценарий при каждом запуске создает новый документ, у которого другой номер с соответствующим заголовком формы и поиск завершается ошибкой.

Так как работа с текстовыми заголовками формы это основной способ взаимодействия платформа позволяет использовать регулярные выражения. Конкретное значение номера и даты заменяем символом '*':

ТестовоеПриложение.НайтиОбъект(Тип("ТестируемоеОкноКлиентскогоПриложения"), "Требование-накладная*", , 30);

В таком виде код работает без ошибок. В таком режиме метод НайтиОбъект находит форму нужного нам документа и взаимодействует с ней.

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

Чтобы обеспечить повторяемость сценария в любых условиях, нужно обеспечить алгоритму доступность кнопки Создать. Алгоритм должен дождаться "окончательного" открытия формы списка документов и уже потом нажать кнопку Создать. Получаем одну из основных проблем UI-теста - ожидание доступности элементов управления форм. Основная причина конечно же база данных, из которой читаются записи для заполнения форм, в данном случае список документов Требование накладная.

Использование различных механизмов ожидания значительно замедляют тесты. Нужно стараться избегать любое ожидания и заменять его другими доступными методами. Воспользуемся методом ВыполнитьКоманду объекта ТестируемоеОкноКлиентскогоПриложения. Как параметр передадим в метод гиперссылку: e1cib/data/Документ.ТребованиеНакладная.

Убираем весь код, который открывает форму списка документов и нажимает на кнопку Создать. Заменяем его одним вызовом ВыполнитьКоманду. Тем самым исключаем ожидание открытия формы списка документов. Форма нового документа открывается очень быстро, т.к. нет чтения данных.

Полученный код работает без ошибок. Можно использовать данный сценарий для автоматизированной проверки функционала документа Требование накладная и его печатных форм.

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

Продолжение: Разработка UI-тестов через запись действий пользователя. Часть 3.