Кровь, пот и тесты. Тестирование в 1С

Коротко о главном

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

К счастью, появилось решение данной проблемы — vanessa-automation. Данный инструмент развивается сообществом и предоставляет набор инструментов для тестирования, и записи видео-инструкций. В него входит: обработка для написания тестов, внешняя компонента для взаимодействия с ОС и расширение для конфигураций - поскольку работая через внешнюю обработку имеется ряд ограничений при работе с конфигурацией (например отслеживание выполнения фоновых заданий).

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

Кровь. Как мы писали тесты

Изначально тесты мы писали просто: есть функционал — пишем тест, который проверяет, что бы при правильном поведении пользователя ничего не ломалось. Это было легко и не отнимало много времени. Правда и пользы было не так много, как хотелось бы. 

Решение «Управление IT-отделом 8» достаточно сложное и есть много вариантов выполнения одного и того же действия. Например, сформировать один и тот же документ «Окончание обслуживания» можно создать, как минимум, напрямую из раздела «Ремонт и обслуживание», из места хранения, на основании документа «Начало обслуживания» и из формы документа «Задание». Везде есть свои особенности реализации создания документа. Все эти варианты нужно тестировать с разными наборами данных.

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

Как результат: тесты стали огромными. Часто написание теста занимало больше времени, чем решение проблемы. Так не годится. Почитав документацию и пообщавшись с сообществом, мы стали выносить наиболее часто используемый в тестах функционал в экспортные сценарии. Например, создание номенклатуры использовалось очень часто и не по одному разу. Это в недавних версиях Vanessa появились соответствующие шаги по созданию объектов ссылочного типа, а в то время мы были лишены такой роскоши и делали все в тестах интерактивно. Были выписаны наиболее распространенные действия и вынесены в «Экспортные сценарии».

Вероятно, следует рассказать чем экспортные сценарии отличаются от обычных? По сути, практически ничем: это такой же файл с шагами для Vanessa, только с меткой @ExportScenarios. Внутри файла располагаются сценарии, которые можно будет вызвать из другого сценария, передав в него параметры. Например, экспортный для перевода задания на другой этап выглядит так:

// Переводит задание с указанным номером на указанный этап, если он доступен.
// Если задание создано не на дату запуска теста, то следует создать переменную "ТекущаяДата" и указать дату документа
Сценарий: Перевожу задание номер "пНомерЗадания" на этап "пЭтап"
И Я запоминаю в переменную "перЭтап" значение "пЭтап"

И я выполняю код встроенного языка на сервере
|'ИдентЭтапа = Неопределено;'|
|'Этап = Справочники.ЭтапыПроцессов.НайтиПоНаименованию(СокрЛП("$перЭтап$"), Истина);'|
|'Если Не Этап = Неопределено Тогда'|
|'ИдентЭтапа = Строка(Этап.УникальныйИдентификатор());'|
|'КонецЕсли;'|
|'Если Не ИдентЭтапа = Неопределено Тогда'|
|'ИмяПоля = "Этап_0_" + Строка(ИдентЭтапа);'|
|'ИмяПоля = СтрЗаменить(ИмяПоля, "-", "");'|
|'Объект.ЗначениеНаСервере = ИмяПоля;'|
|'КонецЕсли;'|

Если не существует переменная "ТекущаяДата" Тогда
И я выполняю код встроенного языка
"""bsl
Контекст.Вставить("ТекущаяДата", Строка(ТекущаяДата()));
"""
И я выполняю код встроенного языка
"""bsl
Контекст.Вставить("ИмяКнопки", Ванесса.Объект.ЗначениеНаСервере);
"""
И Я ищу документ вида "Задание" по номеру "пНомерЗадания" и дате "$ТекущаяДата$"
И я нажимаю на кнопку с именем "$ИмяКнопки$"
И я нажимаю на кнопку с именем "ФормаПровестиИЗакрыть"

Вызвать же этот сценарий из другого просто:

И я перевожу задание номер "31" на этап "Выполнено"

Так же гораздо проще, не правда ли? Казалось, что это отличное решение, но тут, как и в каждом решении, что стремится быть универсальным, есть сложности в реализации. Нужно предусмотреть огромное количество разных вариантов поведения самой 1С. Реализация универсальных экспортных сценариев заняла огромное количество времени и стоила массы нервных клеток.

И вот наступил момент, когда сценарии готовы к повседневному использованию, написана документация с примерами. Что происходит дальше? А дальше мы наблюдаем такую картину, что при написании тестов экспортные используются не очень часто. Вернее, не совсем так: подавляющее большинство сценариев практически не используются, зато сценарии, которые задумывались как вспомогательные, используются в основных тестах крайне охотно. Примером вспомогательного сценария, который стали охотно использовать, стало заполнение объекта по таблице.

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

Пот

Проблему пытались решить распараллеливанием выполнения тестов в нескольких «потоках», но тут возник ряд технических проблем, которые не удалось решить. Например, одной из основных проблем стало лицензирование клиентов тестирования 1С в докер-контейнерах. Параллельно пробовали запускать несколько клиентов тестирования на разных виртуальных рабочих столах, но тут возникала другая проблема: дочерние окна клиента тестирования могли открываться не на своем виртуальном рабочем столе, что приводило к падению тестов. Так же при таком режиме работы даже на достаточно мощном сервере возникали проблемы с отрисовкой интерфейсных объектов самой 1С. Порой эти объекты прорисовывались через несколько секунд после открытия формы, что также не способствовало стабильной работе тестов.

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

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

Тесты

Хоть работа с перестройкой инфраструктуры тестирования еще не закончена, но уже можно подвести некоторый итог. Перечислим все «грабли», по которым наша команда успешно танцевала достаточно много времени:

• сценарии тестирования не должны опираться на данные, что создают другие сценарии тестирования
• экспортные сценарии это неплохо, но они должны быть простыми без сложных ветвлений и тому подобного
• если нужны сложные шаги, которых нет в библиотеки Vanessa, то экспортный сценарий лучше заменить на свои шаги (инструкция по созданию этих шагов будет чуть ниже)
• некоторые технические моменты тестирования в 1С остаются либо нерешенными, либо имеют «специфический» вид

Осталось рассказать, как же, собственно, реализовывать эти «волшебные» собственные шаги для Vanessa. На самом деле все достаточно просто. Первым делом запускаем менеджер тестирования и открываем вкладку «Работа с UI» и пишем наш шаг так, словно он уже существует:

Далее переходим на вкладку «Генерация EPF» и жмем на кнопку «Создать и обновить шаблоны обработок». После этих манипуляций Vanessa сгенерирует обработку и откроет расположение этой обработки.

Запускаем конфигуратор и открываем обработку. Все, что нужно нам для реализации шага располагается в модуле формы.

В первую очередь нас здесь интересует функция «ПолучитьСписокТестов». Именно в ней описывается наш шаг. В принципе из пояснения понятно какие параметры отвечают за что. Например, у нас есть свой шаг заполнения контактной информации. И в этой функции он имеет следующий вид:

Ванесса.ДобавитьШагВМассивТестов(ВсеТесты,"ДляЭлементаСправочникаЯЗаполняюКонтактнуюИнформациюПоТаблице(Парам01,ТабПарам)","ДляЭлементаСправочникаЯЗаполняюКонтактнуюИнформациюПоТаблице","И для элемента справочника ""ИмяСправочника"" я заполняю контактную информацию по таблице
| |'Вид'  |'Значение'  |'Индекс' |
| |'Телефон' |'+79991234567' |'1'  |",
"Заполняет вкладку контактной информации по таблице вида: |""Вид""|""Значение""|""Индекс""|","Мои шаги. Заполнение контактной информации");

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

 Функция ДляЭлементаСправочникаЯЗаполняюКонтактнуюИнформациюПоТаблице(Парам01,ТабПарам) Экспорт

Таблица же, которая следует после шага, передается в нашу функцию через параметр «ТабПарам»
Далее следует получение активного окна:

ФормаЭлемента = Ванесса.ПолучитьАктивноеОкноИзТестовоеПриложение();

СтрокаШапки = ТабПарам[0]; // Заголовки колонок. На данный момент не используются

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

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