Как тестировать механизмы в 1С при работе с хранилищем, не засоряя конфигурацию лишними объектами

При коллективной разработке в 1С использование Хранилища конфигурации является стандартной практикой. Однако разработчики часто сталкиваются с дилеммой: для проверки работы нового отчета или алгоритма требуются тестовые данные. Чтобы эти данные появились, часто нужно создать временные объекты (документы, регистры, обработки), которые не должны попасть в основную конфигурацию и, тем более, к конечному пользователю. Рассмотрим подробнее, как организовать процесс тестирования эффективно и безопасно.

Способ 1. Использование локальной копии базы (автономная разработка)

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

Проанализируем шаги этого метода:

1. Создадим резервную копию информационной базы (файл .dt) или просто скопируем папку с файловой базой.
2. В созданной копии обязательно отключимся от хранилища (Конфигурация — Хранилище конфигурации — Отключиться от хранилища). Теперь мы можем менять любые объекты, не опасаясь за основную ветку разработки.
3. В этой копии добавим любые тестовые документы, регистры или обработки. Наполним их данными и проверим работу нашего отчета.
4. После того как отчет отлажен, мы возвращаемся в основную базу, подключенную к хранилищу.
5. Захватываем в хранилище только тот объект, над которым работали (например, наш отчет), и переносим в него код из локальной копии через буфер обмена или через сравнение/объединение с файлом .cf.

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

Способ 2. Использование внешних обработок для генерации данных

Если для тестирования отчета вам нужно просто записать данные в существующий регистр, нет необходимости создавать новый документ-регистратор в метаданных. Мы можем воспользоваться внешними обработками (файлы .erf).

Рассмотрим пример кода, который можно разместить во внешней обработке для программного заполнения регистра сведений без создания лишних объектов в дереве конфигурации:

МенеджерЗаписи = РегистрыСведений.ЦеныНоменклатуры.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДата();
МенеджерЗаписи.Номенклатура = Справочники.Номенклатура.НайтиПоНаименованию("Тестовый Товар");
МенеджерЗаписи.Цена = 100;
МенеджерЗаписи.Валюта = Справочники.Валюты.НайтиПоКоду("643");
МенеджерЗаписи.Записать();

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

Способ 3. Использование расширений конфигурации (современный подход)

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

Разберем алгоритм работы с расширением:

1. Создаем новое расширение (Конфигурация — Расширения конфигурации).
2. В расширение добавляем все необходимые «мусорные» объекты: тестовые справочники для хранения промежуточных данных, документы-пустышки и т.д.
3. Пишем логику отчета, обращаясь к объектам расширения.
4. Преимущество: расширение не передается в хранилище вместе с основной конфигурацией. Оно живет только в вашей локальной базе.
5. Когда отчет готов, вы переносите финальный вариант кода в основную конфигурацию, а расширение просто удаляете одним кликом.

Обратите внимание: использование расширений требует, чтобы режим совместимости конфигурации был не ниже 8.3.6, а для полноценной работы с данными — еще выше.

Способ 4. Работа с инструментами разработчика

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

Вместо того чтобы создавать объект-регистратор, вы можете открыть консоль ИР, выбрать нужный регистр и вручную добавить в него записи. Это позволяет имитировать наличие данных для отчета мгновенно. После выполнения тестов эти записи так же легко удаляются, не оставляя следов в структуре метаданных. Это исключает необходимость вообще что-либо менять в дереве объектов конфигурации.

Резюме и рекомендации

Подводя итог, выделим лучшие практики при работе с хранилищем:

• Никогда не захватывайте всю конфигурацию целиком, если над проектом работает более одного человека. Это парализует работу всей команды.
• Для создания тестовых данных отдавайте предпочтение внешним обработкам и программному заполнению регистров.
• Если структура данных требует новых объектов метаданных для теста — используйте расширения. Это самый «чистый» способ с точки зрения гигиены хранилища.
• Для сложных задач по отладке всегда держите локальную копию базы, отключенную от хранилища, где вы вольны проводить любые эксперименты.

Помните, что порядок в хранилище конфигурации — это залог стабильности проекта и отсутствия ошибок при обновлении рабочих баз пользователей.