Как организовать контроль доработок и внешних объектов 1С при частых обновлениях конфигурации?

← На главную

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

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

Метод 1. Статический анализ и встроенная проверка конфигурации

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

Рассмотрим шаги для реализации:

Создадим копию базы данных после обновления конфигурации.
Временно загрузим все внешние отчеты и обработки в дерево метаданных конфигурации (в расширение или основную конфигурацию).
Запустим стандартный механизм «Проверка конфигурации» (Меню: Конфигурация — Проверка конфигурации).
Установим флажки «Проверка логической целостности», «Поиск некорректных ссылок» и «Синтаксический контроль».

Этот метод позволяет за один проход выявить все объекты, которые ссылаются на удаленные или переименованные реквизиты и методы. Если Справочник.Номенклатура.РеквизитСтарый был удален, система подсветит все программные модули, где он используется.

Метод 2. Сценарное тестирование и Vanessa-Automation

Если мы хотим быть уверены не только в том, что код компилируется, но и в том, что отчеты корректно формируются, а формы открываются без ошибок, нам не обойтись без сценарного тестирования. Разберем наиболее популярный инструмент — Vanessa-Automation.

Инструмент позволяет записывать действия пользователя (клик по кнопке, ввод текста) и превращать их в исполняемые сценарии на языке Gherkin (человекочитаемый формат). Выясним, как это работает на практике:

Сценарий для проверки внешнего отчета может выглядеть следующим образом:


Функционал: Проверка формирования внешнего отчета "Продажи"

Сценарий: Открытие и формирование отчета
  Дано Я открываю внешнюю обработку "C:\Reports\Sales.erf"
  И в форме "ФормаОтчета" я нажимаю кнопку "Сформировать"
  Тогда я жду появления текста "Итого по отчету" в течение 20 секунд

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

Дымовое тестирование (Smoke testing): Можно настроить автоматический обход всех форм. Система просто будет пытаться открыть каждую форму внешнего объекта. Если форма «падает» с ошибкой при создании — тест помечается как неудачный.
Сравнение результатов: Инструмент позволяет сохранять эталонный результат формирования отчета (например, в виде табличного документа) и сравнивать его с текущим после обновления.
Устойчивость: В отличие от старого «Сценарного тестирования» от 1С, Vanessa более гибко работает с интерфейсом «Такси».

Метод 3. Тестирование программного кода с помощью xUnitFor1C

Для программиста часто важнее проверить не интерфейс, а корректность расчетов в модулях. Рассмотрим подход xUnit, где тесты пишутся на языке 1С. Это быстрее, чем имитировать клики мышкой, и позволяет проверять экспортные функции и процедуры.

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


Процедура ИсполнитьТест_ПроверкаРасчетаСкидки() Экспорт
    // Подготовка данных
    ОбработкаОбъект = ВнешниеОбработки.Создать("C:\Distr\DiscountCalc.epf");
    Цена = 1000;
    Процент = 10;
    
    // Выполнение действия
    Результат = ОбработкаОбъект.РассчитатьСуммуСоСкидкой(Цена, Процент);
    
    // Проверка результата (Утверждение)
    ЮТТесты.ПроверитьРавенство(900, Результат, "Сумма со скидкой рассчитана неверно!");
КонецПроцедуры

Использование xUnitFor1C позволяет автоматизировать проверку бизнес-логики. Проанализируем ситуацию: после обновления ERP изменился алгоритм расчета НДС в общем модуле. Если ваша доработка использует этот модуль, xUnit-тест сразу покажет отклонение в результатах расчетов еще до того, как пользователи заметят ошибку.

Метод 4. Использование EDT и систем контроля версий (Git)

Современный механизм контроля доработок немыслим без использования 1C:Enterprise Development Tools (EDT). В отличие от классического конфигуратора, EDT хранит весь код в текстовом виде. Это дает колоссальное преимущество при обновлении:

Глобальный поиск по проекту: Вы можете искать использование любого объекта метаданных одновременно во всех расширениях и внешних отчетах, которые подключены к вашему рабочему пространству в EDT.
Механизм Git Diff: Мы можем наглядно увидеть, что именно изменилось в коде внешней обработки по сравнению с предыдущей версией.
Статический анализ «на лету»: EDT подсвечивает ошибки (обращение к несуществующим методам) сразу в процессе написания кода, работая аналогично современным IDE для Java или C#.

Как организовать контроль доработок и внешних объектов 1С при частых обновлениях конфигурации?

Метод 1. Статический анализ и встроенная проверка конфигурации

Метод 2. Сценарное тестирование и Vanessa-Automation

Метод 3. Тестирование программного кода с помощью xUnitFor1C

Метод 4. Использование EDT и систем контроля версий (Git)

Рекомендации по документированию и учету

Читайте также