Как тестировать после изменения файла ядра/модуля

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

Ключевые вещи в этой теме: регресс, обновления, не править ядро. Именно их стоит проверить первыми, прежде чем менять код.

Если код выполняется внутри портала, у него есть контекст Битрикса: подключённые модули, текущий пользователь, права, кеш и события. В CLI, cron или внешнем скрипте часть этого контекста нужно создать вручную.

Для CRM, Диска, календаря, пользовательских полей и модулей лучше начинать со штатных API. Прямые SQL-запросы и правка файлов ядра подходят только как крайняя диагностика, а не как основной способ доработки.

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

• Проверьте, где выполняется код: веб, CLI, cron, агент, обработчик события или iframe приложения.
• Подключите нужные модули явно и обработайте ситуацию, когда модуль недоступен.
• Сначала выведите тестовые данные или SQL, затем выполняйте изменение.
• Для боевого портала добавьте логирование результата и ошибок.

• Код проверяют только под администратором, а потом он не работает у сотрудников.
• Доработку кладут в /bitrix или в перегруженный init.php вместо /local или модуля.
• Ошибки не логируются, поэтому после cron, агента или события непонятно, запускался ли код вообще.
• Данные меняют напрямую, минуя операции, события, права, индексы и кеш.

Минимальный регресс:
1. Открыть страницу под администратором.
2. Открыть страницу под обычным сотрудником.
3. Проверить создание, редактирование и удаление.
4. Проверить ajax-действия.
5. Проверить журнал ошибок.
6. Проверить обновление или откат правки.