Обновление конфигурации 1С редко заканчивается самой установкой новой версии. Если в базе используются расширения, внешние обработки и интеграционные модули, после обновления остаётся главный вопрос: продолжат ли они работать с изменившейся конфигурацией?
Обычная проверка конфигурации отвечает на него лишь частично. Расширение может подключаться без явной ошибки, но падать при открытии конкретной формы, обращении к переименованному общему модулю или выполнении кода, который не был вызван во время проверки. В результате проблема обнаруживается уже в рабочей базе — бухгалтером, менеджером или кладовщиком.
Для предварительной проверки таких ситуаций мы разработали 1C Extension Checker 2.0 — самостоятельную внешнюю обработку, которая помогает проверить подключённые расширения и зафиксировать обнаруженные проблемы в едином протоколе.
Какую проблему решает Checker
После обновления типовой конфигурации разработчику обычно приходится вручную открывать формы, запускать команды и проверять наиболее важные сценарии. Это долго, зависит от внимательности проверяющего и не гарантирует, что он доберётся до каждого проблемного участка.
Checker систематизирует первичную техническую проверку. Он проходит по доступным объектам и запускает проверки, которые позволяют обнаружить ошибки, проявляющиеся при компиляции или инициализации модулей и форм.
Например, во время реального тестирования обработка обнаружила ошибку в модуле интеграции форма обращалась к общему модулю, которого уже не было в обновлённой конфигурации. Без целевого открытия этой формы такая проблема могла остаться незамеченной до момента работы пользователя.
Что проверяет 1C Extension Checker 2.0
Обработка предназначена для первого автоматизированного прохода после обновления базы. Она помогает:
найти ошибки компиляции и инициализации модулей;
выявить обращения к отсутствующим или переименованным общим модулям;
обнаружить проблемы, возникающие при открытии форм;
продолжить проверку остальных объектов после закрытия сообщения об ошибке;
собрать результаты в одном протоколе;
отобрать найденные проблемы по статусам;
подготовить текстовый отчёт для передачи разработчику.
Обработка запускается как обычный внешний файл через команду «Файл → Открыть». Для использования не требуется встраивать её в конфигурацию: Checker остаётся самостоятельным инструментом и может применяться в разных информационных базах.
Почему пустой список предупреждений — не ошибка
В Checker предусмотрены отдельные категории результатов, в том числе ошибки, предупреждения и объекты, требующие адаптации. Если после проверки раздел «Предупреждения» или «Адаптация» пуст, это не означает, что команда не сработала. В конкретной базе просто могло не оказаться результатов с таким статусом.
Главным подтверждением работы служит общий протокол: какие объекты были проверены, где проверка прошла успешно и на каком объекте возникла ошибка.
Что автоматическая проверка не может гарантировать
Checker находит технические ошибки, которые удаётся воспроизвести во время запуска проверки. Но отсутствие ошибок ещё не доказывает полную совместимость расширения с новой версией конфигурации.
Есть более сложный класс проблем. Например, расширение добавляет собственный код в типовую процедуру с помощью директив изменения и контроля. После обновления типовая процедура может измениться, но добавленный код по-прежнему будет компилироваться. Формально ошибки нет, однако логика расширения уже может не соответствовать новой реализации типовой конфигурации.
Такую проблему нельзя надёжно обнаружить простым открытием форм. Для неё требуется сравнение версий, анализ изменённых процедур и проверка точек вмешательства расширения.
Поэтому инструменты разделены по назначению:
1C Extension Checker 2.0 выполняет быстрый технический контроль и ищет воспроизводимые ошибки;
1C Extension Auditor станет следующим уровнем — анализом изменений типовой конфигурации и потенциальной несовместимости кода расширений.
Checker не заменяет функциональное тестирование и аудит кода. Его задача — раньше обнаружить очевидные технические поломки и сократить объём ручной проверки.
Практический сценарий использования
Рекомендуемый порядок проверки после обновления выглядит так:
Создать копию информационной базы и установить обновление.
Подключить все расширения и внешние компоненты, используемые в рабочей базе.
Запустить 1C Extension Checker 2.0 через «Файл → Открыть».
Выполнить полную проверку и дождаться завершения прохода.
Просмотреть ошибки, предупреждения и список объектов для адаптации.
Скопировать отчёт для разработчика и передать его вместе с версией конфигурации и расширений.
После исправления ошибок повторить проверку.
Провести функциональное тестирование ключевых бизнес-сценариев перед обновлением рабочей базы.
Что получает разработчик
Вместо сообщения пользователя «после обновления что-то перестало открываться» разработчик получает конкретный объект, модуль и текст ошибки. Это сокращает время на воспроизведение проблемы и позволяет быстрее определить, какое расширение требует исправления.
Текстовый отчёт нужен именно для этого: его можно сохранить, приложить к задаче или отправить разработчику без копирования каждой ошибки вручную.
Итог
1C Extension Checker 2.0 закрывает практическую задачу, знакомую всем, кто сопровождает доработанные базы 1С: быстро проверить расширения после обновления и собрать найденные ошибки в понятный протокол.
Он не обещает доказать абсолютную совместимость — такую гарантию не может дать один автоматический проход. Но Checker позволяет перенести обнаружение значительной части технических проблем из рабочей базы в этап предварительного тестирования. А для анализа изменений логики и точек вмешательства следующим этапом станет 1C Extension Auditor.