Кейс юнит-тестирование (YaxUnit) в Infostart MagicInput

16 июля 2026 · infolimp.ru

Юнит-тестирование (YaxUnit) и инструмент воспроизведения действий (MagicInput) в экосистеме 1С часто воспринимаются как взаимоисключающие. Первый – про изоляцию и скорость, второй – про интеграцию и UI. Кейс, рассмотренный в статье на Infostart, показывает, что их совместное использование позволяет не только сократить время регрессии, но и выявить класс ошибок, которые каждый из инструментов по отдельности пропускает.

Почему MagicInput не панацея, а YaxUnit не самодостаточен

MagicInput отлично справляется с автоматизацией приёмки – воспроизводит цепочки действий пользователя, проверяет реакцию форм. Но при изменении внутренней логики расчёта (например, формулы в обработке заполнения) MagicInput-тест может:

пройти зелёным, если визуально результат совпал, но числовой расчёт был неверен;
упасть из-за незначительного изменения расположения элементов на форме, хотя алгоритм корректен;
требовать полной базы данных и лицензий, что замедляет цикл CI/CD.

YaxUnit, напротив, позволяет написать быстрые автономные тесты на конкретные функции и процедуры. Однако стандартная практика «взять и вызвать тестируемый метод» часто натыкается на жёсткую привязку к глобальному контексту: нужны открытые формы, монопольный режим, активные окна. Именно здесь кейс с Infostart предлагает нетривиальное решение – создать прокси-слой, который имитирует окружение MagicInput, оставаясь при этом в рамках YaxUnit-теста.

Ключевой тезис: YaxUnit тестирует логику, MagicInput – целостность сценария. Только их комбинация даёт доверие к релизу, не превращая тестирование в «гадание на кофейной гуще».

Нетривиальная ловушка: пропуск ошибки из-за несовместимости контекстов

Как MagicInput может «съесть» исключение

Воспроизведение действий через MagicInput – это чёрный ящик. Если обработка, которую вызывает MagicInput, завершается с исключением, MagicInput часто просто прерывает сценарий с общей ошибкой. Разработчик видит «Не удалось выполнить шаг…», но первопричина (например, деление на ноль в процедуре ОбработкаЗаполнения) остаётся скрытой. Приходится запускать MagicInput в отладке, что убивает весь смысл автоматизации.

С другой стороны, если эта же обработка тестируется «напрямую» через YaxUnit, без эмуляции окружения MagicInput, она может отработать корректно, так как недостающие глобальные переменные (например, ПараметрыСеанса.МонопольныйРежим) не сброшены. Ошибка проявится только на реальных данных при реальном запуске.

Что предлагает кейс

Автор статьи на Infostart описывает паттерн: вынести вызов тестируемой обработки в отдельную функцию, которая получает контекст в виде структуры (все входные параметры), а YaxUnit-тест передаёт эту структуру, игнорируя настоящие формы. MagicInput в данном случае используется для записи эталонной структуры параметров (через перехват событий), а YaxUnit – для проверки результата вычислений. Это позволяет:

не зависеть от GUI;
воспроизводить любые комбинации входных данных;
автоматически проверять 100% ветвлений алгоритма.

Сравнение подходов: скорость vs. доверие

Критерий	MagicInput (интеграционные)	YaxUnit (модульные)	Комбинация (кейс)
Время выполнения одного теста	от 30 с до 5 мин	0,01–0,5 с	0,02–1 с (бэкенд)
Зависимость от окружения	Полная база, лицензии	Только код	Только код + эталонные данные
Покрытие UI	100% (визуальная целостность)	0%	0% (UI остаётся за MagicInput)
Выявление скрытых ошибок (неверные расчёты при корректном отображении)	Низкое	Высокое	Высокое (основной фокус)
Сложность поддержки	Высокая (изменения форм ломают сценарии)	Средняя (зависит от рефакторинга)	Средняя (требует согласования протокола передачи параметров)

Как видно, совместное использование закрывает главный недостаток каждого: MagicInput проверяет, что форма открылась, а YaxUnit – что вычисления верны. Ловушка в том, что разработчики часто выбирают что-то одно, а потом тратят дни на отладку багов, которые комбинированный подход отлавливал бы за секунды.

Практическое руководство: как реализовать гибридный тест

Шаг 1. Проектирование контракта

Для каждой обработки, вызываемой MagicInput (например, «ОбработкаЗаполнения»), определите входные параметры как структуру. Выходные данные – тоже структура или таблица значений. Этот протокол будет использоваться и MagicInput (для записи), и YaxUnit (для вызова).

// Пример контракта для обработки "ЗаполнитьЗаказ"
ВходныеПараметры = Новый Структура;
ВходныеПараметры.Вставить("ДокументОснование", СсылкаНаЗаказПокупателя);
ВходныеПараметры.Вставить("Склад", СсылкаНаСклад);
ВходныеПараметры.Вставить("ДатаОтгрузки", ТекущаяДата());

Результат = ВыполнитьОбработкуЗаполнения(ВходныеПараметры);

// Результат - структура с табличной частью и служебными флагами

Шаг 2. Запись эталонного набора через MagicInput

Используйте MagicInput для прогона реального сценария, перехватив момент вызова обработки. Запишите ВходныеПараметры и ожидаемый Результат в файл JSON. Это станет эталоном для YaxUnit.

Шаг 3. Написание YaxUnit-теста с изоляцией

В YaxUnit-тесте необходимо подготовить окружение: подставить заглушки для глобальных объектов (например, ПараметрыСеанса.МонопольныйРежим), но при этом не открывать формы. Для этого можно использовать встроенный механизм ЮТКонтекст из YaxUnit. Если такого механизма нет – реализовать интерфейс-заглушку через свои классы.

// Псевдокод с использованием реального API YaxUnit (через ИТС)
ЮТТест.ДобавитьТест("ТестЗаполненияЗаказа");

Процедура ТестЗаполненияЗаказа() Экспорт
    
    // Подготовка параметров из эталона (загружены из файла)
    ВходныеПараметры = ЭталонныеДанные.Вход;
    
    // Мок для ПараметрыСеанса (через реальные методы YaxUnit)
    // YaxUnit предоставляет объект "ЮТЗаглушкаСеанса" - имя условное
    ЮТЗаглушкаСеанса.Установить("МонопольныйРежим", Ложь);
    // ... другие заглушки
    
    Результат = ВыполнитьОбработкуЗаполнения(ВходныеПараметры);
    
    ЮТОжидание.Равно(Результат.ТабличнаяЧасть.Количество(), 
                     ЭталонныеДанные.Результат.ТабличнаяЧасть.Количество(), 
                     "Количество строк не совпало");
    ЮТОжидание.Истина(Результат.Успех, "Обработка вернула ошибку");
    
КонецПроцедуры

Шаг 4. Запуск в CI/CD

YaxUnit-тесты выполняются «на лету» при каждом коммите (без базы – только код + эталонные данные). MagicInput-тесты – раз в ночь для проверки целостности UI. Провал YaxUnit блокирует сборку, провал MagicInput – предупреждение.

Предупреждение: Никогда не пытайтесь заменить MagicInput-тесты YaxUnit-тестами на 100%. Проверка раскрытия формы, переходов и доступности команд остаётся за MagicInput. YaxUnit берёт на себя проверку алгоритмов, которые невозможно проверить «кликами».

Типичные ошибки при внедрении гибридного подхода

Создание избыточного числа эталонов – записывают каждый прогон MagicInput в эталон, вместо того чтобы выделить типовые варианты (граничные значения, исключительные ситуации). Приводят к раздутию репозитория.
Игнорирование состояния базы – YaxUnit-тесты работают с изолированными данными (через временные справочники), а MagicInput использует боевую базу. Различие в данных может давать ложные
Расширение «НОПик» для 1С — встраиваемый коннектор к внешнему AI с интеллектуальным поиском по базе. Задавайте вопросы обычными словами - AI сам найдёт нужное. 45 дней бесплатно.

Попробовать НОПик →