Как правильно организовать тестирование форм и документов в 1С 8: модульные и сценарные тесты

← На главную

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

Разделение уровней тестирования: юнит-тесты против UI-сценариев

Проанализируем базовое различие между двумя подходами к автоматизации:

Модульные (юнит) тесты: предназначены для быстрой проверки отдельных процедур, функций, алгоритмов общих модулей, модулей менеджеров или объектов без запуска графического интерфейса. Такие тесты оперируют чистыми программными сущностями, работают за доли секунды и проверяют внутреннюю бизнес-логику.
Сценарные (UI / e2e) тесты: моделируют реальные действия пользователя. Именно этот сценарий описывает автор: открыть форму, интерактивно нажать кнопку, заполнить табличную часть, ввести на основании и нажать проведение. Такие тесты требуют открытого клиентского сеанса и эмуляции интерфейсных событий.

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

Решение 1. Сценарное тестирование интерфейса через Vanessa Automation

Наиболее зрелым и общепринятым инструментом для проверки сценариев взаимодействия с пользователем в среде 1С является Vanessa Automation (эволюционное развитие идей Vanessa Behavior). Этот фреймворк реализует подход BDD (Behavior-Driven Development), при котором сценарии составляются на человекопонятном языке Gherkin.

Инструмент подключается к клиенту тестирования платформы и эмулирует действия оператора. Посмотрим на типовой сценарий BDD для проверки заполнения и проведения документа:


Функционал: Проведение документа Реализация товаров и услуг

Сценарий: Создание и успешное проведение документа
    И Я открываю навигационную панель
    И Я выбираю пункт меню "Продажи" "Реализация товаров и услуг"
    И В открывшемся окне я нажимаю кнопку с именем "ФормаСоздать"
    Тогда открылось окно "Реализация товаров и услуг (создание)"
    И Я в поле с именем "Контрагент" ввожу текст "ООО Покупатель"
    И В таблице "Товары" я нажимаю кнопку "Добавить"
    И В таблице "Товары" в поле "Номенклатура" я выбираю значение "Товар 1"
    И В таблице "Товары" в поле "Количество" я ввожу текст "10"
    И В таблице "Товары" в поле "Цена" я ввожу текст "100"
    И Я нажимаю кнопку с именем "ФормаПровестиИЗакрыть"
    Тогда окно "Реализация товаров и услуг (создание)" закрылось

Преимущества данного подхода:

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

Решение 2. Штатный менеджер тестирования платформы 1С

Платформа 1С:Предприятие 8 включает встроенный механизм автоматизированного тестирования. Архитектура построена на взаимодействии двух клиентских сеансов:

Менеджер тестирования: сеанс, запускаемый со специальным ключом /TestManager. В нем исполняется программный код проверки и происходит управление целевым приложением.
Клиент тестирования: сеанс, запускаемый с ключом /TestClient. Это приложение, в интерфейсе которого воспроизводятся клики, ввод значений и навигация.

Для программного управления интерфейсом платформа предоставляет специализированные типы: ТестируемоеПриложение, ТестируемаяФорма, ТестируемоеПолеФормы, ТестируемаяТаблицаФормы. Посмотрим, как выглядит программный код теста на встроенном языке:


Клиент = Новый ТестируемоеПриложение;
Клиент.УстановитьСоединение();

Окно = Клиент.ПолучитьГлавноеОкно();
КомандаСоздать = Окно.НайтиОбъект(Тип("ТестируемаяКнопка"), "ФормаДокументРеализацияСоздать");
КомандаСоздать.Нажать();

ФормаДокумента = Клиент.ПолучитьАктивноеОкно();
ПолеКлиент = ФормаДокумента.НайтиОбъект(Тип("ТестируемоеПолеФормы"), "Контрагент");
ПолеКлиент.ВвестиТекст("ООО Покупатель");

КнопкаПровести = ФормаДокумента.НайтиОбъект(Тип("ТестируемаяКнопка"), "ФормаПровести");
КнопкаПровести.Нажать();

Клиент.РазорватьСоединение();

Необходимо учитывать важные ограничения штатного менеджера тестирования:

Механизм ориентирован только на управляемые формы. Автоматизировать обычные формы через ТестируемоеПриложение невозможно.
Конфигурация должна работать в режиме без использования модальных окон. Любой модальный диалог блокирует сеанс и останавливает тест.
Прямое написание тестов через интерфейсные типы менеджера тестирования требует поддержки большого объема служебного кода, поэтому поверх него чаще всего используют фреймворки-надстройки.

Решение 3. Модульное тестирование логики документов без экранных форм

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

Бизнес-логика проверяется непосредственно через программные объекты. Разберем по шагам, как проверить проведение документа и ввод на основании программным путем:


// Пример проверки проведения и заполнения на основании
Процедура Тест_СозданиеИПроведениеНакладной() Экспорт

    НачатьТранзакцию();
    
    Попытка
        // Шаг 1: Создаем и заполняем документ-основание
        Заказ = Документы.ЗаказПокупателя.СоздатьДокумент();
        Заказ.Дата = ТекущаяДатаСеанса();
        Заказ.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию("ТестовыйКлиент");
        Заказ.Записать(РежимЗаписиДокумента.Проведение);
        
        // Шаг 2: Проверяем ввод на основании
        Накладная = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
        Накладная.Заполнить(Заказ.Ссылка);
        
        // Шаг 3: Проверяем реквизиты после заполнения
        ЮТТест.ПроверитьРавенство(Накладная.Контрагент, Заказ.Контрагент);
        ЮТТест.ПроверитьБольше(Накладная.Товары.Количество(), 0);
        
        // Шаг 4: Проверяем проведение
        Накладная.Записать(РежимЗаписиДокумента.Проведение);
        
        // Шаг 5: Проверяем движения по регистру
        НаборДвижений = РегистрыНакопления.ОстаткиТоваров.СоздатьНаборЗаписей();
        НаборДвижений.Отбор.Регистратор.Установить(Накладная.Ссылка);
        НаборДвижений.Прочитать();
        
        ЮТТест.ПроверитьБольше(НаборДвижений.Количество(), 0);
        
    Исключение
        ОтменитьТранзакцию();
        ВызватьИсключение;
    КонецПопытки;
    
    // Откатываем изменения, чтобы не засорять базу тестовыми данными
    ОтменитьТранзакцию();

КонецПроцедуры

Очистка и изоляция тестовых данных

При тестировании операций записи и проведения документов ключевой задачей становится поддержание чистоты информационной базы:

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