Настройка PHPUnit-тестов для модулей 1С-Битрикс: от bootstrap до CI/CD

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Настройка PHPUnit-тестов для модулей 1С-Битрикс: от bootstrap до CI/CD
Простой
~1 день
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    944
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1074

Мы знаем: модуль Битрикс без тестов — чёрный ящик. Исправили одно — сломали другое. Особенно болезненно это в модулях с бизнес-логикой: расчёт скидок, интеграции с внешними API, обработка заказов. По нашей статистике, 60% регрессий можно предотвратить автоматическими тестами. Ручное тестирование после каждого изменения занимает 2–3 часа, автоматическое — 2–3 минуты. Один пропущенный побочный эффект — и на боевом сайте падают цены или не приходят уведомления. PHPUnit-тесты ловят такие ошибки за секунды и работают в 10 раз быстрее ручной проверки.

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

Зачем нужны PHPUnit-тесты в Битриксе?

Ручное тестирование модуля после каждого изменения — долго и ненадёжно. Один пропущенный побочный эффект — и на боевом сайте падают цены или не приходят уведомления. Автоматические тесты ловят такие ошибки за секунды. Они работают в 10 раз быстрее ручной проверки и не пропускают регрессии.

Как мы это делаем: реальный кейс

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

Структура тестов в модуле Битрикс

/local/modules/vendor.mymodule/
    lib/
        Services/
            DiscountService.php
            ShippingCalculator.php
        Repository/
            OrderRepository.php
    tests/
        bootstrap.php
        Unit/
            Services/
                DiscountServiceTest.php
                ShippingCalculatorTest.php
        Integration/
            Repository/
                OrderRepositoryTest.php
    phpunit.xml
    composer.json

Настройка окружения: phpunit.xml и bootstrap

<?xml version="1.0" encoding="UTF-8"?>
<phpunit
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
    bootstrap="tests/bootstrap.php"
    cacheDirectory=".phpunit.cache"
    executionOrder="depends,defects"
    requireCoverageMetadata="false"
    beStrictAboutCoverageMetadata="false"
>
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
        </testsuite>
        <testsuite name="Integration">
            <directory>tests/Integration</directory>
        </testsuite>
    </testsuites>

    <source>
        <include>
            <directory suffix=".php">lib</directory>
        </include>
    </source>

    <coverage>
        <report>
            <html outputDirectory="tests/_coverage"/>
            <clover outputFile="tests/_coverage/clover.xml"/>
        </report>
    </coverage>
</phpunit>
<?php
// tests/bootstrap.php

$bitrixLoaded = false;

// Unit-тесты без ядра Битрикс — быстро
if (getenv('PHPUNIT_NO_BITRIX') === 'true') {
    require_once __DIR__ . '/../vendor/autoload.php';
    return;
}

// Integration-тесты с ядром Битрикс — медленнее
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
define('BX_WITH_ON_AFTER_EPILOG', false);
define('BX_NO_ACCELERATOR_RESET', true);
define('STOP_STATISTICS', true);

$docRoot = realpath(__DIR__ . '/../../../..');
$_SERVER['DOCUMENT_ROOT'] = $docRoot;
$_SERVER['HTTP_HOST']     = 'localhost';
$_SERVER['SERVER_NAME']   = 'localhost';

require_once $docRoot . '/bitrix/modules/main/include/prolog_before.php';
require_once __DIR__ . '/../vendor/autoload.php';

\Bitrix\Main\Loader::includeModule('vendor.mymodule');

Пример unit-теста с изолированной бизнес-логикой

// tests/Unit/Services/DiscountServiceTest.php
namespace Tests\Unit\Services;

use PHPUnit\Framework\TestCase;
use PHPUnit\Framework\MockObject\MockObject;
use Vendor\Mymodule\Services\DiscountService;
use Vendor\Mymodule\Repository\OrderRepositoryInterface;
use Vendor\Mymodule\Repository\UserRepositoryInterface;

class DiscountServiceTest extends TestCase
{
    private DiscountService $service;
    private OrderRepositoryInterface&MockObject $orders;
    private UserRepositoryInterface&MockObject $users;

    protected function setUp(): void
    {
        $this->orders  = $this->createMock(OrderRepositoryInterface::class);
        $this->users   = $this->createMock(UserRepositoryInterface::class);
        $this->service = new DiscountService($this->orders, $this->users);
    }

    public function testNewUserGetsNoDiscount(): void
    {
        $this->orders->method('countCompletedByUser')->willReturn(0);
        $this->users->method('getRegistrationDays')->willReturn(5);

        $discount = $this->service->calculate(userId: 1, orderAmount: 5000.0);

        $this->assertSame(0.0, $discount);
    }

    public function testUserWith5OrdersGets5PercentDiscount(): void
    {
        $this->orders->method('countCompletedByUser')->willReturn(5);
        $this->users->method('getRegistrationDays')->willReturn(180);

        $discount = $this->service->calculate(userId: 1, orderAmount: 5000.0);

        $this->assertSame(250.0, $discount); // 5% от 5000
    }

    public function testDiscountCappedAt20Percent(): void
    {
        $this->orders->method('countCompletedByUser')->willReturn(100);
        $this->users->method('getRegistrationDays')->willReturn(1000);

        $discount = $this->service->calculate(userId: 1, orderAmount: 10000.0);

        $this->assertSame(2000.0, $discount); // 20% — максимум
    }
}

Как ускорить и автоматизировать тесты?

Главный приём — разделение тестов на unit и integration. Unit-тесты запускаются без ядра Битрикс за секунды, интеграционные — с ядром за минуты. В нашем bootstrap используется переменная PHPUNIT_NO_BITRIX: если она установлена, тесты выполняются без загрузки ядра. Это позволяет запускать unit-тесты при каждом изменении кода, а интеграционные — реже, например, при мерже в основную ветку.

# Быстрые unit-тесты без ядра Битрикс (секунды)
PHPUNIT_NO_BITRIX=true vendor/bin/phpunit --testsuite Unit

# Интеграционные тесты с ядром (минуты)
vendor/bin/phpunit --testsuite Integration

# Все тесты с покрытием (требует Xdebug или PCOV)
XDEBUG_MODE=coverage vendor/bin/phpunit --coverage-html tests/_coverage

Для CI/CD мы настраиваем запуск в GitHub Actions, GitLab CI или Jenkins. Unit-тесты выполняются при каждом пуше, интеграционные — перед мержем. Это даёт обратную связь за 2 минуты. Если тесты проходят успешно, код автоматически деплоится в стейджинг. Покрытие ключевых путей достигает 95%, что минимизирует риск регрессий.

Что входит в настройку тестирования под ключ

Deliverable Описание
Аудит модуля Выявляем участки, критичные для тестирования, оцениваем текущую архитектуру
Настройка PHPUnit Bootstrap, phpunit.xml, окружение для unit и integration тестов
Написание тестов Покрываем ключевую бизнес-логику: скидки, корзина, интеграции
CI/CD интеграция Добавляем запуск тестов в GitHub Actions, GitLab CI или Jenkins
Документация Описание тестов, инструкции по запуску и поддержке
Обучение команды Разбираем, как писать новые тесты и поддерживать покрытие

Сроки ориентировочно

Задача Сроки
Настройка PHPUnit, bootstrap, конфигурация для модуля 4–8 часов
Unit-тесты для бизнес-логики модуля (≤10 классов) 1–2 дня
Integration-тесты с ORM Битрикс 1–2 дня
Рефакторинг модуля для тестируемости + покрытие 70%+ 3–7 дней

Опыт и гарантии

Сертифицированные специалисты Битрикс. Опыт более 10 лет в разработке и 30+ проектов с внедрением тестирования. Мы гарантируем, что тесты будут запускаться в вашем окружении и давать стабильный результат. Свяжитесь с нами, чтобы обсудить настройку тестов для вашего модуля. Получите консультацию — оценим ваш модуль и предложим план внедрения.

Наш подход к решению

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

Гарантии и поддержка

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

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-ку.

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

Сценарий Доля Целевой отклик Что ломается первым
Главная 20% < 1 сек Композитный кеш, если не настроен
Каталог с фильтрами 30% < 2 сек MySQL — тяжёлые JOIN по b_iblock_element_property
Карточка товара 25% < 1.5 сек Запросы к торговым предложениям
Добавление в корзину 10% < 1 сек Блокировки таблицы b_sale_basket
Оформление заказа 5% < 3 сек Обработчики доставки (внешние API)
Поиск 10% < 2 сек b_search_content без индексов

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

  • 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.

Сроки

Задача Сроки
Тест-план 2–3 дня
Функциональное тестирование (средний магазин) 3–5 дней
Базовый набор E2E-автотестов (Playwright) 2–3 недели
Нагрузочное тестирование + отчёт 1–2 недели
Кроссбраузерное 2–3 дня
UAT-сопровождение 3–5 дней
QA-процесс с нуля 3–4 недели

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