Чому інтеграційні тести 1С-Бітрікс ламаються на бою
Інтеграційні тести 1С-Бітрікс найчастіше падають не там, де їх писали. На тестовому стенді обмін з 1С іде по «чистій» базі: довідники синхронні, черги порожні, права збігаються з еталоном.
На бою ті самі сценарії ламаються об розсинхрон даних — номенклатуру перейменували в 1С, а в каталозі залишився старий код; у користувача обміну відкликали роль на читання довідника; черга агентів розрослася і частина подій обробилася поза порядком. Тест «зелений», обмін — ні.
Друга причина — регрес при оновленні. Модуль обміну та обробники подій живуть у двох системах, і після оновлення платформи або модуля змінюється формат пакета, порядок полів або момент виклику агента.
Тест, прив'язаний до попередньої схеми, продовжує проходити, але перевіряє вже не те, що реально йде в 1С. Поки стенд не відтворює бойові черги, права та обсяг довідників, інтеграційні тести 1С-Бітрікс дають хибну впевненість.
Ми розбираємо ці збої за класами: розходження схем обміну, роз'їзд прав доступу, застряглі черги та повторна обробка одних і тих самих записів. Далі — як тестовий стенд наближають до бою і які перевірки ловлять розсинхрон до релізу.
Що дає покриття інтеграційних сценаріїв
Покриття інтеграційних сценаріїв у 1С-Бітрікс — це не «ще один набір автотестів», а перенесення перевірки обміну з ручного режиму у відтворюваний.
Коли вивантаження каталогу, синхронізація залишків, вивантаження замовлень і статусів ідуть через один і той самий контур, регресійний прогін стає обов'язковим кроком перед викатом, а не побажанням.
Саме тут інтеграційні тести 1С-Бітрікс дають вимірюваний ефект: час перевірки релізу падає з годин ручних звірок до хвилин автоматичного прогону, а клас відмов «дані розійшлися, ніхто не помітив» перестає бути штатним сценарієм.
Ручна перевірка обміну погана не швидкістю, а тим, що вона не відтворювана. Інженер перевіряє ті сценарії, які пам'ятає, і на тих даних, що опинилися під рукою — при наступному релізі набір перевірок буде іншим.
Покриття сценаріїв фіксує контракт: які сутності виходять з 1С, у якому вигляді приймаються на стороні сайту, що відбувається при частковому збої та повторному надсиланні. Це переводить стабільність обміну з області «як пощастить» в область перевірюваних тверджень.
Другий ефект — передбачуваність викату. Коли регресійний прогін виконується на кожній зміні, а не раз на квартал, відмови ловляться до продакшену, а не після дзвінка клієнта.
Частка відмов обміну падає не тому, що код став кращим, а тому, що помилки перестали доходити до бойового контуру. Команда бачить, який саме сценарій зламався, і виправляє причину, а не симптом.
Третій ефект — економіка часу. Перевірка релізу перестає бути вузьким горлом: те, що раніше займало день ручних звірок, вкладається в короткий автоматичний прогін. Звільнений час іде на розвиток, а не на повторення одного й того самого набору ручних кроків.
Покриття сценаріїв окупається вже на першому релізі, де ловиться розходження до того, як його побачить клієнт.
Порівняння підходів до тестування обміну
Перевіряти обмін з 1С можна трьома способами, і вибір між ними — це вибір між швидкістю прогону та достовірністю результату.
Ізольовані моки підміняють відповіді 1С заздалегідь підготовленими файлами обміну: прогон займає секунди, але мок не знає, як поводитиметься реальне вивантаження при неповних довідниках або конфлікті версій об'єктів.
Тестовий контур з копією 1С дає чесну картину, але піднімається довше й потребує синхронізації даних. Гібридна схема розділяє ці задачі: швидкі перевірки логіки на моках, критичні сценарії — на живому контурі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ізольовані моки | Регулярні прогони при кожній зміні коду, перевірка розбору та валідації даних | Не ловлять розбіжності форматів і помилки на боці 1С; мок швидко застаріває вслід за реальним вивантаженням |
| Тестовий контур з копією 1С | Приймальні перевірки перед релізом, розбір інцидентів, перевірка нових правил обміну | Довгий підйом оточення, потрібна актуальна копія бази та ізоляція від промислового контуру |
| Гібридна схема | Постійна робота над обміном: часті правки плюс регулярні чесні перевірки | Потребує дисципліни — треба вести обидва набори тестів і стежити, щоб моки не розходилися з контуром |
На практиці вибір визначається частотою змін і ціною помилки. Якщо обмін правиться щотижня, а збій видно лише в промисловому середовищі — гібридна схема окупається: швидкі перевірки відсікають регресії, а контур ловить те, що моки пропускають.
Якщо обмін стабільний і змінюється раз на квартал, достатньо контуру з копією 1С — тримати моки заради пари прогонів невигідно.
Ключове обмеження будь-якого підходу — розсинхрон тестових даних з реальними. Ми фіксуємо структуру довідників і версії об'єктів у самому тесті, щоб прогон падав при розбіжності, а не мовчки пропускав помилку. Далі розбираємо, як це влаштовано в конфігурації та які перевірки закривають обмін.
Етапи впровадження тестового контуру
Впровадження тестового контуру — це не одноразове налаштування, а послідовність кроків, де кожен наступний спирається на результат попереднього.
Починаємо з аудиту інтеграцій: інвентаризуємо обміни з 1С, зовнішніми сервісами та платіжними системами, фіксуємо точки відмови та дані, які мають бути ізольовані від бойової бази. Без цієї карти будь-який тест або ламає прод, або перевіряє не те, що потрібно.
- Аудит інтеграцій. Збираємо перелік обмінів, їхню періодичність, формати та залежності. Визначаємо, які з них можна підміняти, а які зобов'язані працювати по-справжньому.
- Схема оточення. Проєктуємо ізольований контур: окрема база, копія структури каталогів, тестові облікові записи та точки підключення до 1С. Схема фіксується в документі, щоб оточення відтворювалося з нуля.
- Налаштування фікстур. Готуємо набори даних — товари, замовлення, контрагенти, статуси обміну. Фікстури версіонуються разом із кодом: тест піднімає потрібний стан бази та прибирає за собою.
- Прогін тестів. Запускаємо сценарії на ізольованому контурі, звіряємо відповіді обміну з еталоном, ловимо розбіжності в мапінгу полів та обробці помилок. Прогін повторюється на кожній зміні інтеграції.
- Стабілізація. Усуваємо хибні спрацювання, виносимо повільні перевірки в окремий набір, налаштовуємо звіт про покриття обмінів.
- Передача регламентів. Віддаємо команді документацію: як підняти контур, як додати фікстуру, як читати звіт і що робити при падінні тесту.
Після передачі регламентів контур живе без нашої постійної участі — ваші розробники дописують сценарії під нові обміни. Опишіть вашу задачу: подивимося поточні інтеграції та повернемося з оцінкою й планом розгортання.
Що залишається в проєкті після впровадження
Впровадження інтеграційних тестів для 1С-Бітрікс — це не разовий прогін, а набір артефактів, які залишаються в репозиторії та працюють без автора. Нижче — що саме передаємо команді замовника, щоб тести запускалися на чистому середовищі та переживали зміну розробника.
- Конфігурації середовища — файли запуску тестового контуру: параметри підключення до тестової бази, ізольований екземпляр Бітрікс, окрема копія 1С. Піднімається однією командою, не перетинається з робочим контуром.
- Схеми обміну — зафіксовані формати та напрямки: які сутності (замовлення, номенклатура, залишки, контрагенти) синхронізуються, в який бік, з якою періодичністю, що відбувається при розходженні.
- Політики доступу — ролі та права для тестового контуру, окремі облікові записи сервісів, обмеження на запис у продуктивну базу. Тест фізично не може зачепити бойові дані.
- Набори тестових даних — фікстури та сценарії: типові замовлення, граничні випадки (порожній довідник, дубль контрагента, розрив зв'язку), еталонні відповіді для звірки. Дані перевикористовуються між прогонами.
- Скрипти запуску та звіти — єдина команда прогону, звіт з переліком перевірок, що впали, та логом обміну, прив'язка до збірки.
- Документація — як підняти контур, як додати новий сценарій, що робити при падінні тесту, хто власник кожної схеми обміну.
- Регламент підтримки — періодичність прогонів, поріг, при якому збірка блокується, порядок оновлення тестів при зміні обміну.
Такий комплект знімає залежність від конкретного інженера: новий розробник розгортає контур за документацією та бачить причину збою у звіті, а не шукає її в листуванні. Опишіть ваш контур обміну — повернемося з оцінкою та планом.
Кейс: як скоротили відмови обміну втричі
Клієнт — виробнича компанія з інтернет-магазином на 1С-Бітрікс та обліковою системою на 1С.
Обмін замовленнями, залишками та цінами йшов за розкладом, і до втручання команди кожна друга вигрузка завершувалася розбіжністю: частина позицій не оновлювалася, статуси замовлень зависали, менеджери правили дані вручну. Інциденти спливали вже в продажах — клієнт бачив товар у наявності, якого на складі не було.
Що було до
Обмін запускався як єдиний моноліт: один збій на будь-якій позиції валив усю вигрузку, повторний запуск дублював уже записані замовлення.
Діагностика займала години — логи писалися в загальний файл без прив'язки до конкретного пакета, відтворити збій на тестовому контурі не вдавалося, бо середовище не збігалося з робочим.
Що змінили
Розбили обмін на пакети з ідемпотентним записом: повторна обробка того самого пакета не створює дублів, а падіння однієї позиції не зупиняє решту. Підняли тестовий контур з копією структури каталогу та властивостей замовлень, обмін проганяється на ньому перед викаткою.
Логи прив'язали до ідентифікатора пакета — збій локалізується за хвилини, а не за зміну. Реліз обміну тепер іде з прогоном набору перевірок: граничні випадки щодо залишків, скасовані замовлення, зміна ціни в момент вигрузки.
Що стало
Частка збоїв обміну впала втричі, ручні правки залишків і статусів практично зникли. Викатка нової логіки обміну скоротилася з кількох днів до одного релізу на день — зміни перевіряються на тестовому контурі до продакшену, відкат займає хвилини.
Менеджери перестали звіряти дані вручну, а підтримка — розбирати однотипні звернення щодо розбіжностей.
Чим відрізняється інтеграційний тест від модульного?
Модульний тест ізолює одну функцію або метод: підміняє зовнішні виклики заглушками і перевіряє, що логіка повернула очікуваний результат на заданому вході. Він швидкий, детермінований і нічого не знає про те, як код поводитиметься поруч із базою, чергою або зовнішньою системою.
Інтеграційний тест, навпаки, піднімає реальну зв'язку систем і перевіряє поведінку на стику: чи пройшов обмін з 1С, чи лягли дані в інфоблоки, чи відпрацювали права доступу для конкретної ролі.
Межа між ними проходить по тому, що саме ми вважаємо одиницею перевірки. Для модульного тесту це чиста функція — наприклад, розрахунок знижки або розбір рядка.
Для інтеграційного — сценарій цілком: вивантаження номенклатури з 1С, приймання її на боці Бітрікс, оновлення цін і залишків, доступність результату потрібному користувачеві.
Помилка тут майже ніколи не в коді функції — вона в контракті між системами: не той формат поля, втрачений ідентифікатор, розбіжні довідники.
Права доступу — окрема зона, яку модульний тест не покриває в принципі. Перевірити, що менеджер бачить свої замовлення, а гість — лише публічний каталог, можна тільки на зібраному середовищі з реальними ролями та сесіями.
Те саме з даними: інтеграційний тест ловить ситуації, які на заглушках не відтворити — порожні довідники, дублі, частково застосоване вивантаження.
На практиці це не «або», а «і». Модульні тести тримають логіку і дають швидкий зворотний зв'язок на кожну зміну, інтеграційні закривають зв'язку систем і права доступу — те, що ламається під час оновлень і міграцій.
Якщо інтеграційних тестів немає, кожна правка обміну з 1С перевіряється руками, а регрес спливає вже на проді.
Технічні сумніви перед стартом
Перед стартом майже завжди виникають одні й ті самі питання: чи не зламає тестовий контур робочий сайт, чи витримає інфраструктура, чи потрібно переписувати наявний код. Нижче — відповіді по суті, без загальних слів.
Чи сумісно це з нашою поточною версією Бітрікс і 1С?
Так. Тестовий контур розгортається на тій самій гілці ядра й тому самому модулі обміну, що й робочий сайт, — розбіжність версій між середовищами сама по собі ламає тести, тому ми фіксуємо їх синхронно.
Якщо обмін з 1С відбувається через CommerceML або REST, тести працюють з реальними форматами вивантаження, а не зі спрощеними заглушками. Окремо перевіряємо кастомні обробники подій і правки в компонентах — саме вони найчастіше розходяться з типовою логікою.
Чи не просяде продуктивність робочого сайту?
Ні, тому що тести виконуються на ізольованому контурі з окремою базою та власною копією файлів. Навантаження не перетинається з бойовим трафіком, а прогін запускається за розкладом або вручну.
Якщо контур піднімається на тому самому сервері, ми обмежуємо його за ресурсами, щоб пікові перевірки не конкурували з віддачею сторінок.
Який обсяг даних потрібен для достовірних тестів?
Достатньо репрезентативної вибірки: кілька сотень товарів, замовлень і контрагентів з реальними крайовими випадками — порожніми властивостями, довгими назвами, дублями. Повна копія бази не потрібна і лише сповільнює прогін.
Якщо обсяг каталогу великий, ми готуємо зріз за ключовими сутностями й оновлюємо його перед запуском.
Що з підтримкою — тести доведеться переписувати при кожному релізі?
Ні. Тести прив'язані до контрактів обміну та бізнес-сценаріїв, а не до верстки чи внутрішніх деталей. При зміні логіки правиться конкретний сценарій, решта продовжують працювати.
Ми передаємо набір разом з документацією щодо запуску, щоб ваша команда могла доповнювати його самостійно.
Залишилися сумніви щодо вашої конфігурації — опишіть задачу, повернемося з оцінкою та планом.
Обговоримо ваше завдання і повернемося з планом
Щоб запропонувати схему оточення та етапи, нам потрібен контекст проєкту: як влаштований ваш контур, які сценарії критичні, що вже покрито перевірками.
Опишіть завдання у вільній формі — повернемося з планом робіт, де кожен пункт прив'язаний до вашого стеку, а не до абстрактного шаблону.
Що увійде до плану
- Розбір контексту. Дивимося, як пов'язані Бітрікс, 1С і зовнішні сервіси: які обміни йдуть, за яким розкладом, де дані губляться при збоях.
- Схема оточення. Пропонуємо, що піднімати для тестів: окремий контур з копією бази, тестовий вузол 1С, ізольовані черги обміну — щоб перевірки не зачіпали робочі дані.
- Пріоритети сценаріїв. Виділяємо шляхи, які ламаються найчастіше: вивантаження замовлень, синхронізація номенклатури, авторизація, оплата. За ними будуємо перші тести.
- Регламент запуску. Домовляємося, коли проганяються перевірки — перед викладкою, за розкладом чи на кожну зміну, — і хто дивиться звіт.
- Етапи впровадження. Розбиваємо роботу на короткі кроки: спочатку оточення і один наскрізний сценарій, потім розширення покриття і підключення до процесу викладки.
- Точки контролю. Фіксуємо, за якими метриками вважаємо результат: частка покритих шляхів, час прогону, кількість пропущених дефектів на реліз.
Що потрібно від вас
- опис контуру: версії платформи, модулі, зовнішні інтеграції;
- доступи або їхня схема — зрозуміємо, що можна підняти на вашій стороні, а що на нашій;
- список збоїв, які вже траплялися, — це найкраще джерело перших тестів.
Опишіть завдання — повернемося з оцінкою, схемою оточення та етапами.
