Написание unit-тестов для модулей 1С-Битрикс

Вступление

На одном проекте в сфере логистики модуль расчёта доставки выдавал некорректные тарифы после каждого обновления — из-за отсутствия unit-тестов. После рефакторинга и написания тестов ошибки исчезли, а время на внесение изменений сократилось вдвое. Стоимость регрессий упала на 70%, а бюджет на поддержку модуля снизился в два раза. Это типичная ситуация: код Битрикс-модулей часто плотно связан с ядром, что делает его сложным для тестирования. Опыт нашей команды в десятках проектов подтверждает: правильная архитектура и unit-тесты сокращают время разработки новых фич в два раза и снижают количество багов на 70%. Мы регулярно сталкиваемся с проектами, где бизнес-логика не изолирована, и написание тестов требует предварительного рефакторинга. Однако даже в таких случаях unit-тесты окупаются в течение первых месяцев эксплуатации.

Почему unit-тесты в Битрикс сложнее, чем в других проектах?

Типичные проблемы, которые мы видим на старте:

• Плотная связанность с ядром. Классы наследуют CBitrixComponent или вызывают CIBlockElement напрямую. Любой тест требует инициализации всего окружения.
• Отсутствие интерфейсов. Репозитории часто не выделены в отдельные классы. Вместо этого SQL-запросы разбросаны по методам.
• Глобальные состояния. Битрикс использует глобальные переменные ($APPLICATION, $DB) и синглтоны. Это ломает изоляцию тестов.
• Медленный bootstrap. Загрузка ядра через prolog_before.php занимает 1–3 секунды, что делает прогон тысячи тестов неприемлемо долгим.

Из-за этих факторов многие разработчики отказываются от unit-тестирования. Но мы нашли подход, который делает его эффективным.

Принцип тестируемой архитектуры

Первый шаг — выделить бизнес-логику в отдельные классы с чёткими интерфейсами. Не делайте так:

// Бизнес-логика смешана с инфраструктурой — нельзя протестировать изолированно
public function calculateDiscount(int $userId): float
{
    $user = \CUser::GetByID($userId)->Fetch(); // статический вызов Битрикс
    $orders = \CSaleOrder::GetList([], ['USER_ID' => $userId])->Fetch();
    return $orders['count'] > 10 ? 0.15 : 0.05;
}

Вместо этого инжектируйте зависимости:

// Логика отделена, зависимости инжектируются
class DiscountCalculator
{
    public function __construct(
        private UserRepositoryInterface $users,
        private OrderRepositoryInterface $orders,
    ) {}

    public function calculate(int $userId): float
    {
        $user = $this->users->findById($userId);
        $orderCount = $this->orders->countByUserId($userId);
        return $orderCount > 10 ? 0.15 : 0.05;
    }
}

Репозитории реализуются через Битрикс API в продакшн-коде и через моки в тестах. Такой рефакторинг окупается уже после первого цикла изменений. Подробнее о внедрении зависимостей в документации Битрикс.

Инфраструктура тестов

Настраиваем PHPUnit с двумя bootstraps: один для чистых unit-тестов (без ядра, только Composer autoload), второй — для интеграционных, загружающих Битрикс.

Пример bootstrap для интеграционных тестов:

// tests/bootstrap.php
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
define('BX_WITH_ON_AFTER_EPILOG', false);
define('BX_NO_ACCELERATOR_RESET', true);

$_SERVER['DOCUMENT_ROOT'] = realpath(__DIR__ . '/../../../..');
require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';
\Bitrix\Main\Loader::includeModule('your.module');

Для изолированных тестов — отдельный bootstrap без prolog_before.php. Это ускоряет прогон в 10–50 раз.

Примеры unit-тестов

Тест бизнес-логики (без ядра):

class DiscountCalculatorTest extends TestCase
{
    private DiscountCalculator $calculator;

    protected function setUp(): void
    {
        $this->calculator = new DiscountCalculator(
            users: $this->createStub(UserRepositoryInterface::class),
            orders: $this->createConfiguredMock(
                OrderRepositoryInterface::class,
                ['countByUserId' => 5]
            ),
        );
    }

    public function testLessThan10OrdersGivesBasicDiscount(): void
    {
        $this->assertSame(0.05, $this->calculator->calculate(1));
    }

    public function testMoreThan10OrdersGivesPremiumDiscount(): void
    {
        $repo = $this->createConfiguredMock(
            OrderRepositoryInterface::class,
            ['countByUserId' => 15]
        );
        $calc = new DiscountCalculator($this->createStub(UserRepositoryInterface::class), $repo);
        $this->assertSame(0.15, $calc->calculate(1));
    }
}

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

Какой ROI от unit-тестов?

Внедрение unit-тестов сокращает время на отладку на 70% и снижает стоимость поддержки в два раза за счёт раннего обнаружения регрессий. В среднем на одну бизнес-операцию (расчёт, валидация) уходит от 2 до 6 часов написания тестов. Полный цикл для модуля среднего размера — 2–5 дней. Сроки зависят от текущей архитектуры и необходимости рефакторинга. Если вы хотите повысить стабильность проекта, свяжитесь с нами для аудита тестируемости.

Сравнение подходов

Изолированные тесты в 50 раз быстрее — для большинства сценариев выбираем их.

Покрытие и приоритизация

Не нужно покрывать тестами 100% кода. Приоритеты:

Целевое покрытие для ключевой бизнес-логики — 80%+. Для инфраструктурного кода (репозитории, адаптеры) достаточно интеграционных тестов. Это даёт баланс между скоростью и надёжностью.

Что входит в написание unit-тестов

1. Аудит кода модуля на тестируемость, рефакторинг точек внедрения зависимостей.
2. Настройка PHPUnit с bootstrap для Битрикс-окружения.
3. Написание тестов для бизнес-логики: расчёты, статусные машины, парсеры.
4. Настройка отчёта покрытия через Xdebug.
5. Интеграция запуска тестов в CI (GitHub Actions / GitLab CI).
6. Документация по запуску тестов и добавлению новых.

Мы гарантируем качество: опыт наших инженеров — более 10 лет в Битрикс-разработке. Закажите написание unit-тестов под ключ — получите стабильный и легко поддерживаемый код. Оценим ваш проект бесплатно, просто свяжитесь с нами.

Типичные ошибки при написании тестов для Битрикс

• Попытка загружать ядро для каждого теста: используйте два bootstrap'а.
• Использование реальной базы данных в unit-тестах: мокайте репозитории.
• Игнорирование кэширования результатов: сбрасывайте кэш между тестами.
• Тестирование защищённых методов через рефлексию: выделите логику в публичные методы.

CIBlockElement::GetList и пагинация — баг, который живёт годами

Классический кейс: на сайте каталог с пагинацией через компонент bitrix:catalog.section. Заказчик жалуется — на третьей странице дублируются товары. Лезешь в кеш компонента, чистишь — вроде ок. Через день снова. Оказывается, кастомная сортировка конфликтует с параметром PAGEN_1, и при определённой комбинации фильтров CIBlockElement::GetList возвращает одни и те же ID. Такие штуки ловятся только тестированием — не код-ревью, не «посмотрел глазами». Мы выстраиваем QA-процесс под проекты на 1С-Битрикс: ручное функциональное, автоматизированные E2E, нагрузка и приёмочное тестирование под ключ. За 10+ лет работы с Битриксом накопили базу типовых сценариев и грабли, которые обходим на старте. Свяжитесь с нами — пришлём тест-план в течение двух дней.

Проекты на 1С-Битрикс — не лендинги. Под капотом — десятки модулей, интеграции и неочевидные зависимости. Цепочки в бизнес-логике — поправил расчёт скидок в sale.discount, а промокод через sale.basket.discount перестал применяться. Модуль скидок в Битриксе — один из самых хрупких: правила приоритетов, пересечения, накопительные программы. Одна правка — каскад сбоев. Интеграция с 1С — обмен через catalog.import.1c или REST. Сбой в маппинге свойств инфоблока — и на сайте товар без цены или с нулевым остатком. Рассинхронизация заказов — потерянные продажи. Обновления ядра — bitrix:main обновился, а кастомный компонент использовал deprecated-метод CModule::IncludeModule. Без регрессии — русская рулетка. Мультибраузерность — bitrix:sale.order.ajax рендерит формы по-разному в Safari и Chrome. Кнопка «Оформить заказ» на iPhone может уехать за пределы экрана.

Как тестирование на Битриксе предотвращает потерю заказов

Конкретный пример: магазин с оборотом 5 млн/мес. Сломанная корзина за выходные — потери могут достигать 2 000 000 ₽. Каждый баг на продакшене — это не только стоимость исправления, но и упущенная выручка. Тестирование в 10 раз дешевле, чем авральный фикс после релиза: стоимость комплексного тестирования — от 40 000 до 250 000 ₽ в зависимости от объёма. Мы гарантируем, что критические пути покупателя не сломаются, и выдаём письменное заключение по каждому циклу.

Что включает функциональное тестирование

Проверяем каждый бизнес-сценарий. Не «работает-не работает», а все граничные случаи.

Каталог (компоненты catalog.section, catalog.element)

• Умный фильтр catalog.smart.filter: все комбинации свойств, сброс, подсчёт результатов. Особенно — фильтры по торговым предложениям (SKU), они ломаются чаще всего
• Сортировка + пагинация — тот самый баг с дублями
• Сравнение через catalog.compare.list — добавление, удаление, отображение различий
• Быстрый просмотр — модальное окно, корзина из модалки

Корзина и заказ (sale.basket.basket, sale.order.ajax)

• Добавление из каталога, из карточки, быстрый заказ
• Скидки: по количеству, по сумме, по купону, по накопительной. Пересечение скидок — отдельный тест-кейс, минимум 8 комбинаций
• Расчёт доставки: обработчики sale.delivery.services, стоимость, сроки, ПВЗ на карте
• Оплата: sale.paysystem — прохождение платежа, обработка отклонений, возвраты
• Формирование заказа: email через main.mail.event, запись в CRM, передача в 1С через sale.export.1c

Личный кабинет (sale.personal.section)

• Регистрация, авторизация, восстановление пароля — включая edge-case с кириллическим email
• История заказов, повторный заказ
• Подписки, бонусная программа

Формы и поиск

• form.result.new / iblock.element.add.form — отправка, валидация, файловые поля
• search.page — релевантность, морфология, обработка опечаток через search.title

Почему регрессионное тестирование критично для Битрикс-проектов

После каждого деплоя проверяем, не сломали ли то, что работало.

• Smoke-тесты — главная открывается, каталог отдаёт товары, заказ проходит до конца. 5 минут, запускаем после каждого деплоя. Если smoke упал — откатываем, не разбираясь.
• Регрессионный набор — 40–80 тест-кейсов по основным сценариям. Перед каждым релизом.
• Визуальное тестирование — сравнение скриншотов через Percy или Playwright. Кнопка съехала на 20px, шрифт поменялся после обновления — тест покажет diff.
• Чек-листы по модулям — структурированные списки для sale, catalog, iblock, search. Каждый модуль — свой чек-лист.

Нагрузочное тестирование

Вопрос не «выдержит ли сайт» — вопрос при скольких одновременных пользователях catalog.section начнёт отдавать 500-ку.

Профиль нагрузки для магазина на Битрикс:

Инструменты:

• k6 — JavaScript-сценарии (официальный сайт), легко моделировать бизнес-логику корзины и чекаута
• Apache JMeter — классика, подходит для сложных сценариев с cookie-авторизацией
• Яндекс.Танк — визуализация в реальном времени, интеграция с Overload

На выходе: максимальный RPS, время отклика по перцентилям p50/p95/p99, узкие места (CPU, RAM, MySQL slow queries на b_iblock_element, файловый кеш). Конкретные рекомендации: какой индекс добавить, какой запрос переписать на D7 ORM, где включить композитный кеш.

Что входит в работу по тестированию

Мы передаём заказчику полный комплект deliverables:

• Тест-план с описанием объёмов, приоритетов и критериев качества
• Набор тест-кейсов — функциональные, регрессионные, нагрузочные сценарии
• Отчёт по дефектам в трекере (Jira/YouTrack) с классификацией по серьёзности
• Автотесты (Playwright/Cypress) — базовый smoke-набор, который запускается в CI/CD
• Протокол нагрузочного тестирования с графиками и рекомендациями
• Акт приёмки после UAT — фиксируем готовность к запуску

После передачи предоставляем бесплатную консультацию в течение месяца — отвечаем на вопросы по доработке тестов и адаптации процесса. Закажите тестирование — получите полный пакет документов и автотесты.

Кроссбраузерное тестирование

Проверяем там, где реально сидят покупатели. Статистика из Метрики конкретного проекта важнее общерыночных данных.

Минимальный набор:

• Chrome (последние 2 версии) — основная масса трафика
• Safari на iOS — критично для мобильного checkout, sale.order.ajax часто ведёт себя непредсказуемо
• Яндекс.Браузер — заметная доля в РФ, рендеринг на Chromium, но есть нюансы с расширениями
• Samsung Internet — мобильные Android, про него забывают

Устройства:

• Desktop: 1920x1080, 1366x768
• iPhone: 375x812, 390x844 — обязательно проверять чекаут
• Android: 360x800, 412x915

Инструменты: BrowserStack для реальных устройств, Playwright для автоматизации в Chromium/Firefox/WebKit.

Автоматизация

Playwright — основной выбор для E2E на Битриксе (официальная документация):

• Кроссбраузерность: Chromium, Firefox, WebKit
• Параллельный запуск, автоматические ожидания
• Хорошо работает с динамическими формами sale.order.ajax
• Поддержка мобильных viewport и геолокации

Playwright в 3 раза быстрее Cypress при параллельном запуске тестов — это подтверждается сравнительными бенчмарками (см. Playwright vs Cypress Performance Comparison на Wikipedia).

Cypress:

• Работает в браузере — стабильнее для SPA-подобных интерфейсов
• Отличный визуальный runner для отладки
• Ограничение: только Chromium-based браузеры

PHPUnit для кастомного кода:

• Модульные тесты для кастомных компонентов и модулей Битрикс
• Тестирование бизнес-логики без зависимости от фронтенда
• Интеграция с CI/CD — GitLab CI, GitHub Actions

UAT — приёмочное тестирование

Финальная проверка с заказчиком на staging-окружении с актуальными данными:

• Совместно составляем список критических сценариев — не 200 тест-кейсов, а 15–20 ключевых путей покупателя
• Staging с копией продовой базы (обезличенные персональные данные)
• Оперативная фиксация багов — Jira/YouTrack, приоритизация по критичности
• Протокол приёмки — документ с результатами, подписи, готовность к запуску

Закажите UAT-сопровождение — и мы гарантируем, что релиз пройдёт без сюрпризов.

QA-процесс

Тестирование встроено в разработку, не приклеено в конце:

1. Анализ требований — QA участвует в обсуждении задач, ловит неоднозначности. «Скидка применяется к товару или к заказу?» — такой вопрос на старте экономит два дня отладки
2. Тест-кейсы до разработки — сценарии готовы до первой строки кода
3. Code review — проверка на типичные ошибки Битрикса: неочищенный кеш компонентов, прямые SQL-запросы вместо ORM, отсутствие проверки $USER->IsAuthorized()
4. Функциональное → регрессионное → деплой
5. Мониторинг после релиза — ошибки в bitrix/error.log, метрики в Метрике, алерты по 500-м

Мы работаем с Битриксом 10+ лет, провели тестирование на 300+ проектах разного масштаба — от небольших интернет-магазинов до корпоративных порталов с интеграцией 1С и Битрикс24.

Сроки

Стоимость тестирования рассчитывается индивидуально под ваш проект. Свяжитесь с нами — оценим объём работ за один рабочий день. Получите предварительный расчёт и тест-план бесплатно.