Вопрос уверенности в работоспособности кода — один из самых острых в разработке на платформе 1С:Предприятие, особенно когда речь идет о сложных внедрениях уровня 1С:ERP. Проблема усугубляется огромными объемами баз данных (500 Гб и выше), сложностью обновления конфигураций и тесной связью логики с данными. В этой статье мы подробно разберем проверенные временем методики и современные инструменты, которые позволяют минимизировать количество ошибок и повысить доверие заказчика к выпускаемым релизам.
Разберем типичную ситуацию: у разработчика есть задача, но тестирование на «пустой» базе не дает гарантий, а полная копия продуктивной базы весит слишком много для развертывания на каждом рабочем месте. Проанализируем эффективные стратегии решения этой проблемы:
Для качественного процесса разработки недостаточно одного сервера. Рассмотрим рекомендованную схему из четырех контуров, которая позволяет отсекать ошибки на разных этапах:
Важно понимать, что нарушение этой цепочки и попытки «тестировать сразу в проде» неизбежно ведут к деградации качества системы.
Чтобы код был тестируемым, он должен быть модульным. Выясним причину, почему это важно: если алгоритм расчета скидки жестко «зашит» в процедуру проведения документа, его невозможно проверить, не создавая всю цепочку объектов в базе. Разберем пример правильной организации кода:
// Плохой подход: логика внутри процедуры проведения
Процедура ОбработкаПроведения(Отказ, Режим)
// ... 500 строк кода с запросами и расчетами
КонецПроцедуры
// Хороший подход: вынос логики в экспортную функцию
Функция РассчитатьСуммуСкидки(ПараметрыРасчета) Экспорт
// Чистая математика и логика
Возврат Результат;
КонецФункции
Используя модульный подход, мы можем применять юнит-тесты. Для этого в экосистеме 1С существует инструмент xUnitFor1C. Мы можем создать отдельную обработку-тест, которая будет вызывать нашу функцию с разными входными параметрами и проверять результат.
Современный стандарт тестирования в 1С — это подход BDD (Behavior Driven Development). Рассмотрим, как это работает на примере инструмента Vanessa Automation. Мы пишем сценарий на языке, понятном человеку (Gherkin), и система сама выполняет действия в пользовательском интерфейсе 1С.
Пример сценария:
Дано: Я открываю документ "Заказ клиента"
Когда: Я заполняю поле "Количество" значением "10"
И: Я нажимаю кнопку "Рассчитать"
Тогда: Поле "Сумма" должно быть равно "1000"
Такие автотесты позволяют реализовать регрессионное тестирование. Это означает, что при каждом обновлении системы мы запускаем робота, который «прокликивает» все важные участки. Если после ваших правок в одном модуле «отвалился» другой — автотест сразу сообщит об этом.
Даже если тесты пройдены, код может быть «грязным» или неоптимальным. Разберем по шагам, как организовать ревью в команде:
Попытка...Исключение, отсутствие «жестких» ссылок на конкретные элементы справочников в коде.Пример того, что должен ловить ревьюер:
// Ошибка, которую найдет ревьюер или статический анализатор
Для Каждого СтрокаТЧ Из Товары Цикл
// Запрос в цикле — убийца производительности на больших данных
СкладскойОстаток = ПолучитьОстатокНаСкладе(СтрокаТЧ.Номенклатура);
КонецЦикла;
Для крупных проектов с 20 и более разработчиками жизненно необходим CI/CD (Continuous Integration / Continuous Deployment). Посмотрим на этот процесс в разрезе автоматизации:
Когда разработчик помещает код в хранилище или делает commit в Git, автоматически запускается скрипт (например, в GitLab CI). Он создает временную базу, загружает туда новую конфигурацию, прогоняет тысячи тестов Vanessa Automation и, в случае успеха, формирует файл поставки или обновляет тестовый контур. Это позволяет обнаруживать ошибки в течение минут, а не через неделю после релиза на продуктив.
Чтобы минимизировать количество ошибок «на данных заказчика», придерживаемся следующих правил:
Если...Тогда, всегда предусматривайте ветку Иначе, в которой вызывайте ВызватьИсключение с понятным текстом. Это поможет быстро локализовать проблему, когда придут «неожиданные» данные.ЗначениеЗаполнено() — ваш лучший друг.ЖурналРегистрации. При ошибке на стороне заказчика вам не придется гадать, что пошло не так.Подведем итог: стопроцентная уверенность в коде — это недостижимый идеал, но комбинация из правильной архитектуры серверов, автоматизированных тестов и Code Review позволяет сократить количество инцидентов на порядок. Начните с малого: внедрите обязательное модульное тестирование для самых критичных участков (например, расчет зарплаты или налогов) и постепенно переходите к полной автоматизации.