Пишем интеграционные тесты для Битрикс: настройка окружения и примеры

Почему интеграционные тесты 1С-Битрикс ломаются на бою

Интеграционные тесты 1С-Битрикс чаще всего падают не там, где их писали. На тестовом стенде обмен с 1С идёт по «чистой» базе: справочники синхронны, очереди пусты, права совпадают с эталоном. На бою те же сценарии ломаются о рассинхрон данных — номенклатуру переименовали в 1С, а в каталоге остался старый код; у пользователя обмена отозвали роль на чтение справочника; очередь агентов разрослась и часть событий обработалась вне порядка. Тест «зелёный», обмен — нет.

Вторая причина — регресс при обновлении. Модуль обмена и обработчики событий живут в двух системах, и после обновления платформы или модуля меняется формат пакета, порядок полей или момент вызова агента. Тест, привязанный к прежней схеме, продолжает проходить, но проверяет уже не то, что реально уходит в 1С. Пока стенд не воспроизводит боевые очереди, права и объём справочников, интеграционные тесты 1С-Битрикс дают ложную уверенность.

Мы разбираем эти сбои по классам: расхождение схем обмена, разъезд прав доступа, застрявшие очереди и повторная обработка одних и тех же записей. Дальше — как тестовый стенд приближают к бою и какие проверки ловят рассинхрон до релиза.

Что даёт покрытие интеграционных сценариев

Покрытие интеграционных сценариев в 1С-Битрикс — это не «ещё один набор автотестов», а перенос проверки обмена из ручного режима в воспроизводимый. Когда выгрузка каталога, синхронизация остатков, выгрузка заказов и статусов идут через один и тот же контур, регрессионный прогон становится обязательным шагом перед выкатом, а не пожеланием. Именно здесь интеграционные тесты 1С-Битрикс дают измеримый эффект: время проверки релиза падает с часов ручных сверок до минут автоматического прогона, а класс отказов «данные разошлись, никто не заметил» перестаёт быть штатным сценарием.

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

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

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

Сравнение подходов к тестированию обмена

Проверять обмен с 1С можно тремя способами, и выбор между ними — это выбор между скоростью прогона и достоверностью результата. Изолированные моки подменяют ответы 1С заранее подготовленными файлами обмена: прогон занимает секунды, но мок не знает, как поведёт себя реальная выгрузка при неполных справочниках или конфликте версий объектов. Тестовый контур с копией 1С даёт честную картину, но поднимается дольше и требует синхронизации данных. Гибридная схема разделяет эти задачи: быстрые проверки логики на моках, критичные сценарии — на живом контуре.

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

Ключевое ограничение любого подхода — рассинхрон тестовых данных с реальными. Мы фиксируем структуру справочников и версии объектов в самом тесте, чтобы прогон падал при расхождении, а не молча пропускал ошибку. Дальше разбираем, как это устроено в конфигурации и какие проверки закрывают обмен.

Этапы внедрения тестового контура

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

1. Аудит интеграций. Собираем перечень обменов, их периодичность, форматы и зависимости. Определяем, какие из них можно подменять, а какие обязаны работать по-настоящему.
2. Схема окружения. Проектируем изолированный контур: отдельная база, копия структуры каталогов, тестовые учётные записи и точки подключения к 1С. Схема фиксируется в документе, чтобы окружение воспроизводилось с нуля.
3. Настройка фикстур. Готовим наборы данных — товары, заказы, контрагенты, статусы обмена. Фикстуры версионируются вместе с кодом: тест поднимает нужное состояние базы и убирает за собой.
4. Прогон тестов. Запускаем сценарии на изолированном контуре, сверяем ответы обмена с эталоном, ловим расхождения в маппинге полей и обработке ошибок. Прогон повторяется на каждом изменении интеграции.
5. Стабилизация. Устраняем ложные срабатывания, выносим медленные проверки в отдельный набор, настраиваем отчёт о покрытии обменов.
6. Передача регламентов. Отдаём команде документацию: как поднять контур, как добавить фикстуру, как читать отчёт и что делать при падении теста.

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

Что остаётся в проекте после внедрения

Внедрение интеграционных тестов для 1С-Битрикс — это не разовый прогон, а набор артефактов, которые остаются в репозитории и работают без автора. Ниже — что именно передаём команде заказчика, чтобы тесты запускались на чистом окружении и переживали смену разработчика.

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

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

Кейс: как сократили отказы обмена втрое

Клиент — производственная компания с интернет-магазином на 1С-Битрикс и учётной системой на 1С. Обмен заказами, остатками и ценами шёл по расписанию, и до вмешательства команды каждая вторая выгрузка завершалась расхождением: часть позиций не обновлялась, статусы заказов зависали, менеджеры правили данные руками. Инциденты всплывали уже в продажах — клиент видел товар в наличии, которого на складе не было.

Что было до

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

Что изменили

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

Что стало

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

Чем отличается интеграционный тест от модульного?

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

Граница между ними проходит по тому, что именно мы считаем единицей проверки. Для модульного теста это чистая функция — например, расчёт скидки или разбор строки. Для интеграционного — сценарий целиком: выгрузка номенклатуры из 1С, приём её на стороне Битрикс, обновление цен и остатков, доступность результата нужному пользователю. Ошибка здесь почти никогда не в коде функции — она в контракте между системами: не тот формат поля, потерянный идентификатор, разошедшиеся справочники.

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

На практике это не «или», а «и». Модульные тесты держат логику и дают быструю обратную связь на каждое изменение, интеграционные закрывают связку систем и права доступа — то, что ломается при обновлениях и миграциях. Если интеграционных тестов нет, каждая правка обмена с 1С проверяется руками, а регресс всплывает уже на проде.

Технические сомнения перед стартом

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

Не просядет ли продуктив рабочего сайта?

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

Какой объём данных нужен для достоверных тестов?

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

Что с поддержкой — тесты придётся переписывать при каждом релизе?

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

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

Обсудим вашу задачу и вернёмся с планом

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

Что войдёт в план

• Разбор контекста. Смотрим, как связаны Битрикс, 1С и внешние сервисы: какие обмены идут, по какому расписанию, где данные теряются при сбоях.
• Схема окружения. Предлагаем, что поднимать для тестов: отдельный контур с копией базы, тестовый узел 1С, изолированные очереди обмена — чтобы проверки не задевали рабочие данные.
• Приоритеты сценариев. Выделяем пути, которые ломаются чаще всего: выгрузка заказов, синхронизация номенклатуры, авторизация, оплата. По ним строим первые тесты.
• Регламент запуска. Договариваемся, когда прогоняются проверки — перед выкладкой, по расписанию или на каждое изменение, — и кто смотрит отчёт.
• Этапы внедрения. Разбиваем работу на короткие шаги: сначала окружение и один сквозной сценарий, затем расширение покрытия и подключение к процессу выкладки.
• Точки контроля. Фиксируем, по каким метрикам считаем результат: доля покрытых путей, время прогона, число пропущенных дефектов на релиз.

Что нужно от вас

• описание контура: версии платформы, модули, внешние интеграции;
• доступы или их схема — поймём, что можно поднять на вашей стороне, а что на нашей;
• список сбоев, которые уже случались, — это лучший источник первых тестов.

Опишите задачу — вернёмся с оценкой, схемой окружения и этапами.