UI-тестирование
April 20, 2021

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

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

В предыдущей заметке с помощью разработчика удалось запустить "записанный" тест в режиме 1С:Предпритие. Внешняя обработка передана консультанту, который будет запускать ее и после обновления базы типовой конфигурации. Оговорюсь, что он был сделан на базе релиза Бухгалтерии предприятия 3.0.79.14, который вышел в июне 2020 года. База обновляется типовыми релизами один раз в месяц. Документ Требование накладная достаточно стабильный с точки зрения изменений формы. Мы рассчитываем, что данный тест будет служить нам достаточно долго без существенных изменений.

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

Но вот настал момент когда и этот классический функционал кардинально изменился. Произошло это в марте 2021 года в следствии изменений стандартов РСБУ. Вот так изменились формы:

Слева форма "было", справа "стало"

После обновления тест перестал работать, но до этого работал 8 месяцев и не пропустил ошибок в рабочую базу. Можно ли быстро поправить код теста или нужно заново пройти весь путь разработки?

Причины первой ошибки очевидны - форма документа изменила название. Исправление тоже простое. Заменяем словосочетание "Требование-материалов" на "Расход материалов".

Значение не является значением объектного типа (НайтиОбъект)
ФормаТребованиеНакладнаяСоздание = ОкноПриложения.НайтиОбъект(Тип("ТестируемаяФорма"), "Требование-накладная (создание)");

Следующая ошибка менее очевидная - алгоритм не может найти на форме поле Склад, хотя оно есть:

Значение не является значением объектного типа (ВвестиТекст)
ПолеСклад.ВвестиТекст("осн");

Оказывается поле просто переместилось между группами элементов, слева направо. Небольшое исправление и шапка документа заполнилась.

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

При таких изменениях в форме документа придется серьезно дорабатывать и код сделанный по "правильному" подходу. Но существенное отличие в том, что изменений будет значительно меньше, т.к. они будут сосредоточены в одной процедуре заполнения формы документа. Изменение одной процедуры позволят работать тестам, которые ее используют, сколько бы их не было. Автотесты разработанные через запись придется полностью переделывать. Трудозатраты на поддержку и развитие автотестов при этих двух подходах несопоставимы.

Еще один вывод это без разработчиков автоматизированное тестирование невозможно. На текущий момент, ни один инструмент не позволит специалисту без навыков разработки, регулярно запускать и поддерживать автотесты.