При разработке крупных, высоконагруженных систем на платформе «1С:Предприятие» — таких как интеграционные модули, подсистемы обмена EDI или микросервисные API — стабильность кода выходит на первый план. Любое изменение в общем модуле может лавинообразно нарушить работу смежных блоков. В классическом программировании для минимизации этих рисков применяется модульное (юнит) тестирование. Однако в мире 1С разработчики часто сталкиваются с проблемой выбора подходящего инструмента.
Исторически сложилось так, что старый фреймворк xUnitFor1C перестал развиваться и некорректно работает на современных версиях платформы (начиная с 8.3.13 и выше, особенно в режиме управляемых форм). В то же время популярные BDD-инструменты (поведенческое тестирование), такие как Vanessa Automation, кажутся избыточными для простых проверок чистого кода. В этой статье мы подробно разберем, как эффективно организовать модульное тестирование в 1С, используя современные инструменты и методологии.
В процессе обсуждения путей решения этой задачи разработчики обычно разделяются на два лагеря:
xddRunner (модернизированный и поддерживаемый аналог старого xUnit). Это позволяет писать классические тест-кейсы на встроенном языке 1С, полностью игнорируя сценарные файлы Gherkin (фичи).Давайте подробно проанализируем оба подхода, выявим их сильные и слабые стороны, а также разберем практические примеры написания тестов.
Если в вашей компании уже используется Vanessa Automation для сценарных тестов, логично применить её движок и для модульного тестирования. В составе Ванессы есть обработка, которая умеет искать тестовые методы в общих модулях и выполнять их.
Для организации процесса выполним следующие шаги:
Тест_ или ЮТ_ (например, Тест_ОбработкаДанныхEDI).Рассмотрим пример тестирования функции расчета контрольной суммы передаваемого EDI-пакета:
// Общий модуль: Тест_ОбработкаДанныхEDI
// Процедура проверяет корректность расчета контрольной суммы для строки
Процедура Тест_РасчетКонтрольнойСуммыСтроки_Успешно() Экспорт
// Arrange (Подготовка данных)
ВходнаяСтрока = "EDI_PAYLOAD_DATA_2023";
ОжидаемыйРезультат = "987FBC88"; // Предполагаемая верная контрольная сумма
// Act (Выполнение действия)
ФактическийРезультат = EDI_ИнтеграцияСервер.РассчитатьКонтрольнуюСумму(ВходнаяСтрока);
// Assert (Проверка утверждения с помощью Vanessa Assert)
// В xddRunner доступен глобальный контекст проверки
Тестирование.ПроверитьРавенство(ФактическийРезультат, ОжидаемыйРезультат, "Контрольные суммы не совпадают!");
КонецПроцедуры
Преимущества подхода с Vanessa Automation:
Недостатки:
Если вам нужен легкий, быстрый и современный инструмент, ориентированный исключительно на программистов, мы рекомендуем обратить внимание на YAxUnit (Yet Another xUnit for 1C). Этот фреймворк спроектирован по образу и подобию JUnit и xUnit в мире .NET/Java.
YAxUnit поставляется в виде расширения конфигурации YAxUnit.cfe. Главная его фишка — глубокая интеграция со средой разработки 1С:EDT (Enterprise Development Tools) через специальный плагин. Это позволяет запускать тесты прямо из панели EDT одним кликом и сразу видеть результат в виде зеленой или красной полосы.
При написании тестов в YAxUnit активно применяется концепция Fluent API (текучий/удобный интерфейс утверждений). Давайте разберем по шагам, как написать модульный тест для проверки API-функции валидации входящего JSON от веб-сервиса EDI.
Создадим тестовый метод в расширении и разметим его аннотацией:
// [Тест]
Процедура Тест_ВалидацияВходящегоПакета_ДолжнаВернутьЛожьПриПустойСтруктуре() Экспорт
// Arrange: Создаем пустую структуру, которая заведомо не пройдет валидацию
ВходящийПакет = Новый Структура;
// Act: Вызываем метод валидации нашей системы
РезультатВалидации = EDI_ПротоколСервер.ПакетВалиден(ВходящийПакет);
// Assert: Используем лаконичный синтаксис Fluent API YAxUnit
ЮТТест.ОжидаетЧто(РезультатВалидации)
.Равно(Ложь)
.ИмеетТип("Булево");
КонецПроцедуры
Разберем, почему синтаксис ЮТТест.ОжидаетЧто(...).Равно(...) удобнее классических проверок. Во-первых, код становится легко читаемым, как обычный текст. Во-вторых, при падении такого теста среда выдаст максимально информативную ошибку, например: "Ожидалось значение [Ложь], но было получено [Истина] с типом [Булево]".
При тестировании интеграций EDI («микросервисов» на базе 1С) основной проблемой является зависимость тестируемого метода от внешних факторов: доступности API провайдера, сетевых задержек или состояния базы данных. Настоящий модульный тест не должен ходить в реальную сеть или создавать реальные документы в базе данных. Для предварительной отладки и интерактивной проверки API подойдёт обработка для тестирования HTTP-сервисов и отправки GET/POST-запросов.
Для решения этой проблемы применяются заглушки (Mocks/Stubs). Разберем ситуацию: метод ОтправитьДокументВEDI(ИдентификаторДокумента) отправляет HTTP-запрос к провайдеру. Мы хотим протестировать логику обработки успешного ответа сервера 1С, не отправляя реальный HTTP-запрос.
Для этого в тестовом расширении мы переопределяем или перехватываем метод отправки сетевого запроса. Сделать это можно с помощью встроенных механизмов мокирования YAxUnit или через штатный механизм расширений 1С (метод &Вместо):
&Вместо("ОтправитьHTTPЗапрос")
Функция Тест_ОтправитьHTTPЗапрос_Заглушка(АдресРесурса, ТелоЗапроса)
// Вместо обращения к реальному серверу EDI возвращаем подготовленный тестовый ответ
ТестовыйОтвет = Новый Соответствие;
ТестовыйОтвет.Вставить("КодСостояния", 200);
ТестовыйОтвет.Вставить("Тело", "{""status"": ""accepted"", ""message_id"": ""test_12345""}");
Возврат ТестовыйОтвет;
КонецФункции
Таким образом, наша бизнес-логика отработает в полной изоляции, проверив корректность разбора JSON-ответа и изменения статусов в нашей базе данных, не выполняя сетевых транзакций.
Написать тесты — это только половина дела. Чтобы они приносили пользу, они должны запускаться автоматически при каждом коммите разработчика в Git-репозиторий. Если тесты не запускаются автоматически, про них быстро забывают, и они устаревают.
Современный пайплайн сборки проекта на 1С выглядит следующим образом:
Внедрение модульного тестирования в 1С — это инвестиция, которая окупается уже на первых этапах модернизации крупных систем. Для успешного старта рекомендуем придерживаться следующих правил: