Проверка расширения 1С перед запуском в рабочую базу

Программист принёс расширение: «Доработал печатную форму, всё работает». Вы подключили его в рабочую базу, а через час бухгалтер пишет, что проведение реализации стало занимать минуту. Чтобы протестировать расширение 1С без таких сюрпризов, проверяйте его на копии базы, по заранее составленному списку сценариев и до подключения к живым данным.

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

Сначала тестовая база: без неё результатам нельзя верить

Тест на пустой базе ничего не доказывает. Тест на рабочей базе опасен. Нужна копия, максимально похожая на «боевую».

Как сделать копию

1. Выгрузите рабочую базу: в Конфигураторе Администрирование → Выгрузить информационную базу (получится файл .dt).
2. Создайте новую пустую базу на том же сервере или локально и загрузите туда этот файл через Администрирование → Загрузить информационную базу.
3. Проверьте, что платформа и релиз конфигурации в копии те же, что в рабочей базе.

Что поправить в копии, чтобы не навредить

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

• 📧 регламентные задания, которые отправляют почту и уведомления;
• 🔄 обмены с другими базами, сайтом, банком;
• 📡 подключения к ЭДО и онлайн-кассам;
• 🔑 реальные пароли и токены интеграций.

Заметно упрощает жизнь пометка в названии: «ТЕСТ расширения». Её видно в заголовке окна, и никто не спутает базы.

Состав тестовых данных

Нужны не только «хорошие» документы. Заведите набор:

Какие бывают проверки и что из них обязательно

Не всё нужно запускать каждый раз. Выбирайте по тому, что расширение делает.

Начните с проверки конфигурации

Самый дешёвый тест делается за минуту. В Конфигураторе откройте Конфигурация → Проверка конфигурации и отметьте проверки, относящиеся к синтаксису и вызовам. Для расширений в диалоге есть отдельные настройки, посмотрите их при запуске. Платформа найдёт несуществующие методы, неверные вызовы и необъявленные переменные.

Если проверка ругается на расширение, дальше можно не идти: сначала исправления.

Ручное тестирование: что пройти руками

Ручной прогон нужен всегда. Автоматика ловит только то, что вы догадались описать.

Как составить сценарии

Берите не абстрактные «проверить документ», а конкретные действия пользователя от начала до конца. Хороший сценарий записывается так: что открыть, что нажать, что должно получиться.

Пример для расширения, которое добавляет реквизит «Номер заказа клиента» в реализацию:

1. Создать документ реализации, заполнить на основании заказа.
2. Убедиться, что новый реквизит появился на форме и заполнился.
3. Провести документ , проверить, что проведение не изменилось.
4. Открыть печатную форму, найти в ней новое поле.
5. Скопировать документ , проверить, что реквизит скопировался.
6. Пометить на удаление и снять пометку.
7. Открыть список документов и проверить сортировку и отбор по новому полю.

Чек-лист на любую доработку

Журнал регистрации после прогона

Отдельный полезный шаг: сразу после ручного прогона откройте журнал регистрации (Администрирование → Журнал регистрации в Конфигураторе или в режиме 1С:Предприятие через меню сервисных функций) и отберите события уровня «Ошибка». Иногда пользователь ничего не заметил, а в журнале уже лежит исключение из фонового задания.

Автоматическое тестирование: инструменты и пример

Автоматика окупается, когда расширение живёт долго и обновляется. Один раз описали сценарии, дальше они прогоняются за минуты.

Два подхода

• 🧪 Модульные тесты. Проверяют отдельные процедуры и функции кода: подали вход, сравнили результат. Для 1С популярны открытые фреймворки вроде xUnitFor1C и YAxUnit. Они запускаются в самой платформе.
• 🖱 Сценарные тесты. Имитируют работу пользователя в интерфейсе: открыть форму, заполнить, нажать. Для этого применяют Vanessa Automation, она читает сценарии на языке Gherkin.

Оба инструмента бесплатные и живут на GitHub. Конкретные команды установки зависят от версии, поэтому берите их из документации проекта, а не из памяти.

Как выглядит сценарий

Сценарий Vanessa Automation читается почти как обычный текст:

Функционал: Реквизит "Номер заказа клиента" в реализации

Сценарий: Реквизит заполняется при вводе на основании заказа
  Когда я открываю список документов "Реализация товаров и услуг"
  И я создаю документ на основании заказа клиента
  Тогда поле "Номер заказа клиента" заполнено
  И я провожу документ без ошибок

Конкретные фразы берутся из библиотеки шагов инструмента. Придумывать свои не нужно: достаточно выбрать готовые.

Что автоматизировать в первую очередь

Не пытайтесь покрыть всё. Начните с трёх вещей:

1. Самый частый сценарий (создание и проведение главного документа).
2. Всё, что расширение перехватывает у типовой конфигурации.
3. Ошибки, которые уже случались: каждый найденный баг превращается в тест, чтобы не вернуться.

Проверка скорости: как найти узкие места

Расширение может работать правильно, но тормозить. Особенно часто виноваты запросы в цикле, обращение к реквизитам через точку и тяжёлые подписки на события.

Простой замер без инструментов

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

Что смотреть дальше

• 📊 Технологический журнал. Он пишет долгие вызовы и запросы к СУБД. Настраивается файлом logcfg.xml в каталоге конфигурации платформы. Фильтруйте по длительности, чтобы журнал не раздулся.
• 🔍 Замер производительности. Встроенные средства платформы показывают, какие процедуры занимают время.
• 🗄 Блокировки. Если расширение пишет данные в проведении, проверьте, не появились ли ожидания на блокировках при работе нескольких пользователей.

Типичные причины тормозов в коде расширений

Совместимость: как расширение переживёт обновление

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

Порядок проверки перед обновлением

1. Сделайте копию рабочей базы вместе с подключённым расширением.
2. Обновите копию до нового релиза конфигурации по штатной процедуре.
3. Откройте список расширений: Конфигурация → Расширения конфигурации. Расширения, которые перестали быть совместимыми, помечаются предупреждением.
4. Запустите проверку конфигурации ещё раз.
5. Повторите ручной и автоматический прогон из предыдущих разделов.

Только после этого обновляйте рабочую базу.

На что смотреть в первую очередь

• 🧩 Перехватываемые методы: у типовой процедуры могли измениться параметры или поведение.
• 🗂 Объекты, на которые ссылается расширение: их могли переименовать или удалить.
• 📝 Заимствованные формы: если типовая форма изменилась, заимствованная копия в расширении может отстать от неё.
• 🔖 Режим совместимости расширения. Он задаётся в свойствах расширения и должен соответствовать платформе, на которой вы работаете.

Что чаще всего идёт не так при тестировании

Этот раздел не про шаги, а про привычки, из-за которых пропускают дефекты.

• 🚫 Тестирует автор. Разработчик проверяет только то, что предусмотрел. Дайте пройти сценарии тому, кто будет работать: бухгалтеру, менеджеру.
• 🚫 Только администратор. У пользователя с полными правами всё открывается. Ошибка «Недостаточно прав» проявится у рядового сотрудника.
• 🚫 Тест на чистой базе. Без реальных справочников и остатков не видны ни скорость, ни странные данные.
• 🚫 Нет повторного прогона после правок. Исправили один дефект, сломали соседний. После каждой правки пройдите хотя бы основной сценарий.
• 🚫 Тест в рабочей базе «на минуточку». Побочные эффекты (отправка писем, обмены) срабатывают по-настоящему.

Как зафиксировать результаты

Если результаты тестов остаются в голове, при следующем обновлении всё придётся начинать заново. Достаточно простой таблицы.

Что записывать

Текст ошибки копируйте целиком, в обратных кавычках, например: Поле объекта не обнаружено. По точной формулировке разработчик найдёт причину быстрее, чем по описанию «не работает ».

Итоговое решение

В конце составьте короткий вывод: можно подключать, нужны доработки, откладываем. Подпись заказчика или ответственного избавит от споров, если позже что-то пойдёт не так.

Частые вопросы