Вопрос автоматизированного тестирования в экосистеме 1С долгое время оставался прерогативой энтузиастов, однако с развитием платформы и усложнением конфигураций он перешел в разряд критически важных компетенций разработчика. Рассмотрим подробнее, как организовать процесс тестирования, какие участки кода требуют особого внимания и какие инструменты актуальны сегодня.
Одной из главных ошибок начинающих является желание «покрыть тестами всё». Проанализируем ситуацию: полная проверка интерфейса и логики огромной конфигурации требует колоссальных трудозатрат, которые часто не окупаются. Опытные разработчики рекомендуют использовать прагматичный подход, выбирая цели для тестирования по следующим критериям:
Рассмотрим подробнее вопрос тестирования интерфейса. Большинство экспертов сходится во мнении, что автоматизировать нажатия кнопок в 1С значительно сложнее и дороже, чем проверять программный код. Тесты интерфейса крайне хрупкие: малейшее изменение порядка обхода или переименование элемента формы ломает сценарий. Поэтому основной упор стоит делать на юнит-тестирование (модульное тестирование) серверной логики.
Запросы в 1С — это «отдельная песня». Основная сложность здесь заключается в подготовке тестовых данных. Разберем по шагам эффективный сценарий тестирования сложного запроса:
ТаблицуЗначений или XML. При последующих запусках теста система будет автоматически сравнивать новый результат запроса с эталоном.Посмотрим на пример логики организации теста для запроса:
Процедура Тест_ПроверкаОстатковПоСкладу() Экспорт
// 1. Подготовка данных
СоздатьТестовыйТовар("Печенье", 100);
СоздатьТестовыйТовар("Конфеты", 50);
// 2. Выполнение тестируемого запроса
РезультатЗапроса = ВыполнитьЗапросОстатков();
// 3. Сравнение с ожиданием (Assert)
ЮнитТест.ПроверитьТаблицу(РезультатЗапроса, ЭталоннаяТаблица);
КонецПроцедуры
За годы развития сообщество 1С выработало несколько мощных инструментов. Выясним причину популярности каждого из них:
SnowTest (модуль Я_Тест): классический инструмент для юнит-тестирования в обычных формах. Он позволяет писать тесты прямо внутри конфигурации, используя встроенный язык. Для его работы часто требуется добавление общего модуля, что может быть неудобно в типовых конфигурациях.
xUnitFor1C: современный стандарт для технического тестирования. Этот фреймворк вобрал в себя лучшие практики из мира Java и .NET (xUnit/JUnit). Он позволяет группировать тесты, использовать плагины и интегрироваться с системами непрерывной разработки. Основное преимущество — возможность работы в режиме «браузера тестов», где разработчик видит дерево тестов и результаты их выполнения в реальном времени.
Vanessa-Automation (и подход BDD): если нужно тестировать поведение системы с точки зрения пользователя, используются инструменты класса BDD (Behavior-Driven Development). Сценарии пишутся на человекочитаемом языке Gherkin:
Функционал: Проверка оформления заказа
Сценарий: Оформление розничного покупателя
Дано Я открываю форму списка документов "ЗаказПокупателя"
Когда Я нажимаю кнопку "Создать"
И Я заполняю поле "Контрагент" значением "Розничный покупатель"
Тогда Поле "Сумма" должно быть равно 0
При тестировании часто возникает необходимость изолировать тестируемый код от внешних систем (например, чтобы тест не пытался реально отправить email или стучаться в банк). Для этого используются Mock-объекты (заглушки). В 1С это реализуется через подмену вызовов функций или использование обработок-заглушек.
Еще одна интересная идея, которую мы проанализируем — использование штатного Замера производительности для оценки покрытия кода тестами. Запуская тест под замером, мы можем увидеть, какие строки кода были исполнены, а какие остались незатронутыми. Это позволяет понять «белые пятна» в нашей системе тестирования.
Для эмуляции действий в формах можно использовать внедрение специального метода:
Процедура _Выполнить(Метод, ПараметрыМетода = Неопределено) Экспорт
Если ПараметрыМетода = Неопределено Тогда
Выполнить(Метод);
Иначе
// Логика вызова с параметрами
КонецЕсли;
КонецПроцедуры
Этот метод позволяет тесту «дотянуться» до экспортных процедур модуля формы и эмулировать нажатия кнопок или изменение реквизитов, не прибегая к сложным внешним инструментам управления окнами.
Подведем итог нашему анализу. Чтобы начать внедрение автоматизированного тестирования, не нужно пытаться переписать всё. Начните с малого:
ОтменитьТранзакцию()). Это позволит тестам не засорять базу данных мусором.Помните, что тестирование — это не дополнительные затраты, а инвестиция в стабильность системы. В долгосрочной перспективе наличие автоматизированных проверок сокращает время на отладку и поиск ошибок, позволяя команде сосредоточиться на создании новой функциональности.