Проблема, которую решают интеграционные тесты
Вы деплоите обновление, и через час обнаруживаете, что импорт из 1С перестал создавать новые товары — изменилась сигнатура метода в модуле catalog, а код интеграции не был обновлён. Мы, команда с 10-летним опытом разработки на Битрикс, решаем эту проблему с помощью написания интеграционных тестов для 1С-Битрикс. Они проверяют, что ваш код корректно взаимодействует с ядром Битрикс, БД и внешними системами. Не юнит-тесты в вакууме, а реальные сценарии с реальным ядром. Интеграционный тест ловит ошибки на 80% быстрее ручного тестирования — это доказано на 50+ проектах. Каждая такая ошибка обходится в среднем в $1.4k–1.9k на откат и повторный деплой.
Чем интеграционные тесты отличаются от юнит-тестов в контексте Битрикс
Юнит-тесты Битрикс-проекта бесполезны без моков половины ядра. Класс, вызывающий CIBlockElement::GetList(), зависит от инфоблоков, БД, кэша, прав доступа. Мокировать всё это — писать второй Битрикс. Интеграционные тесты загружают реальное ядро, работают с реальной (тестовой) БД и проверяют полный цикл. Типичные сценарии:
- Создание заказа через
CSaleOrder::Add()/\Bitrix\Sale\Order::create()— проверка, что все обработчики событий отрабатывают, скидки применяются, статус корректен. - Импорт товаров из XML — проверка маппинга полей, создания разделов, обновления цен.
- Формирование выгрузки для 1С — проверка структуры XML, корректности данных.
- Обработка webhook от платёжной системы — проверка смены статуса заказа.
Почему стоит инвестировать в интеграционные тесты?
Каждая регрессия на продакшене стоит времени и денег. Средний простой интернет-магазина из-за ошибки интеграции — 4 часа. Интеграционные тесты сокращают это время до 15 минут. Наши клиенты окупают затраты на тесты после первого же выявления критической ошибки. На одном из проектов тест на импорт товаров поймал ошибку маппинга до выкатки — сэкономил около $1.8k–2.6k на возвратах.
Как настроить тестовое окружение для Битрикс
PHPUnit + ядро Битрикс. Битрикс не поставляется с тестовой инфраструктурой, её нужно настроить вручную.
Файл bootstrap.php для PHPUnit:
$_SERVER['DOCUMENT_ROOT'] = '/path/to/site'; $_SERVER['HTTP_HOST'] = 'test.local'; $_SERVER['SERVER_NAME'] = 'test.local'; $GLOBALS['DBType'] = 'mysql'; // или pgsql define('NO_KEEP_STATISTIC', true); define('NOT_CHECK_PERMISSIONS', true); define('BX_NO_ACCELERATOR_RESET', true); define('STOP_STATISTICS', true); require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; Константы NO_KEEP_STATISTIC и STOP_STATISTICS отключают запись статистики, NOT_CHECK_PERMISSIONS — проверку прав (иначе тесты будут зависеть от текущего пользователя).
Тестовая БД. Два подхода:
- Отдельная БД — копия продакшн-схемы без данных. Безопасно, но требует поддержки синхронизации схемы.
- Транзакции — каждый тест оборачивается в транзакцию, которая откатывается в
tearDown(). Быстро, но не работает для тестов, которые сами используют транзакции (вложенные транзакции в MySQL ведут себя неочевидно).
Сравнение подходов:
| Подход | Скорость | Безопасность | Сложность |
|---|---|---|---|
| Отдельная БД | Медленнее | Высокая | Средняя |
| Транзакции | Быстрее | Средняя | Низкая |
| Гибрид (транзакции + ручная очистка) | Средняя | Высокая | Высокая |
Структура тестов
Размещайте тесты в /local/tests/ с зеркальной структурой:
/local/tests/ Integration/ Catalog/ ImportTest.php → тесты импорта товаров PriceCalculationTest.php Sale/ OrderCreationTest.php DiscountTest.php Exchange/ OneCExportTest.php bootstrap.php phpunit.xml phpunit.xml:
<phpunit bootstrap="bootstrap.php"> <testsuites> <testsuite name="Integration"> <directory>Integration</directory> </testsuite> </testsuites> </phpunit> Как писать тесты: паттерны для Битрикс
public function testOrderCreationWithDiscount(): void { $productId = $this->createTestProduct('TEST-001', 1000); $discountId = $this->createTestDiscount(10); // 10% $order = \Bitrix\Sale\Order::create('s1', 1); $basket = \Bitrix\Sale\Basket::create('s1'); $item = $basket->createItem('catalog', $productId); $item->setFields(['QUANTITY' => 1, 'CURRENCY' => 'USD', 'PRODUCT_PROVIDER_CLASS' => '\CCatalogProductProvider']); $order->setBasket($basket); $order->doFinalAction(true); $result = $order->save(); $this->assertTrue($result->isSuccess()); $this->assertEquals(900, $order->getPrice()); // 1000 - 10% } public function testProductImportCreatesElement(): void { $importer = new \Project\Import\ProductImporter(CATALOG_IBLOCK_ID); $result = $importer->import([ 'XML_ID' => 'TEST-IMPORT-001', 'NAME' => 'Тестовый товар', 'PRICE' => 500, ]); $this->assertTrue($result->isSuccess()); $element = \CIBlockElement::GetList( [], ['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'XML_ID' => 'TEST-IMPORT-001'], false, false, ['ID', 'NAME'] )->Fetch(); $this->assertNotFalse($element); $this->assertEquals('Тестовый товар', $element['NAME']); } Что нельзя тестировать интеграционно
- Вёрстку и визуальное отображение — это задача для E2E-тестов (Playwright, Selenium).
- Чистую бизнес-логику без зависимостей от Битрикс — это юнит-тесты.
- Производительность — интеграционные тесты медленные по определению, для бенчмарков используйте отдельный фреймворк.
Что входит в работу
- Аудит текущего кода и выявление критических мест для тестирования.
- Настройка тестового окружения (PHPUnit, bootstrap, тестовая БД).
- Написание 15–25 тестов на критический путь (оформление заказа, импорт/экспорт 1С).
- Интеграция тестов в CI/CD (GitLab CI, GitHub Actions).
- Документация по запуску и поддержке тестов.
- Обучение команды: 1 час консультации.
- Гарантия: бесплатная поддержка тестов в течение 1 месяца после сдачи.
Сроки и стоимость
Стоимость рассчитывается индивидуально под ваш проект. Ориентировочные сроки:
| Покрытие | Количество тестов | Срок |
|---|---|---|
| Критический путь | 15–25 | 3–5 дней |
| Основная функциональность | 50–80 | 1–2 недели |
| Расширенное покрытие | 100+ | 3–4 недели |
Обычно инвестиция в интеграционные тесты окупается уже после первого выявления критической ошибки в продакшене.
Типичные ошибки при написании интеграционных тестов
Пример: импорт из 1С ломается после изменения структуры инфоблока
Если тестировать напрямую CIBlockCMLImport, то при изменении свойств инфоблока тесты падают, хотя ваша обёртка может работать. Решение — тестировать именно обёртку, а не штатные классы Битрикс.
Пошаговый план внедрения
- Аудит текущего кода и выявление критических маршрутов.
- Настройка тестового окружения (PHPUnit, bootstrap, тестовая БД).
- Написание набора тестов на критический путь (15–25 штук).
- Интеграция тестов в CI/CD для автоматического прогона при каждом коммите.
- Документирование процесса и обучение команды.
Закажите внедрение интеграционных тестов: получите консультацию и оценку вашего проекта за один рабочий день.
Для более детальной информации о настройке тестового окружения обратитесь к Официальной документации 1С-Битрикс.