Тестирование интеграций доставки 1С-Битрикс: от расчёта до трекинга

Мы тестируем интеграции доставки в 1С-Битрикс не по чек-листу, а с погружением в бизнес-логику. За период работы проведено более 50 аудитов для интернет-магазинов с оборотом от 5 млн ₽. Типичная картина: расчёт стоимости возвращает 0, ПВЗ не грузится, трек-номер не приходит. И всё это без ошибок на экране. Наша задача — найти такие сценарии до того, как они ударят по клиентам. Проводим нагрузочное тестирование доставки для оценки времени отклика API.

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

Почему сбой в расчёте доставки остаётся незамеченным?

80% проблем в расчёте доставки связаны с отсутствием габаритов товаров или неверным кодом города. CDEK API v2 при пустом weight возвращает 400, модуль Битрикс молча отдаёт 0. Покупатель видит только "доставка не рассчитана" и уходит. Мы проверяем raw-запросы к API и находим такие расхождения до деплоя.

Архитектура интеграции доставки в Битрикс

Службы доставки подключаются через модуль sale как обработчики доставки (класс \Bitrix\Sale\Delivery\Services\Base). Для каждой службы есть отдельный класс с реализацией:

• calculateConcrete() — расчёт стоимости
• createShipment() — создание отправления во внешней системе (если реализовано)
• getTrackingInfo() — получение статуса трекинга

Кастомные обработчики размещаются в /local/php_interface/include/sale_delivery/. Стандартные модули служб доставки (CDEK, DHL, DPD, Boxberry, PickPoint, СДЭК) устанавливаются из Маркетплейса.

Что тестировать

Расчёт стоимости доставки

Первая и самая частая точка отказа. Проверяют:

• Корректность расчёта для разных габаритов товара (нужны товары с заполненными WEIGHT, WIDTH, HEIGHT, DEPTH в каталоге)
• Работу при отсутствии габаритов у части товаров в корзине
• Корректность зон доставки — тариф для Москвы не должен применяться к Владивостоку
• Кэширование расчётов: повторный запрос той же корзины должен возвращать результат из кэша, не дёргая внешний API

// Проверяем кэш расчёта доставки
$cacheManager = \Bitrix\Main\Data\Cache::createInstance();
$cacheKey = 'delivery_calc_' . md5(serialize($basketItems) . $cityCode);
if ($cacheManager->initCache(3600, $cacheKey, '/sale/delivery/calc')) {
    $cachedResult = $cacheManager->getVars();
} else {
    $result = $deliveryService->calculate($shipmentItemCollection, $extraServices);
    $cacheManager->startDataCache();
    $cacheManager->endDataCache($result);
}

Выбор ПВЗ

Виджеты CDEK, Boxberry, PickPoint грузят карту через JS. Тестируют:

• Загрузку виджета на всех целевых браузерах
• Корректную передачу выбранного ПВЗ в форму оформления
• Сохранение выбранного ПВЗ при обновлении страницы
• Поведение при недоступности JS (graceful degradation)

Создание отправления

Проверка того, что заказ корректно регистрируется в ЛК службы доставки при смене статуса в Битрикс:

// Обработчик события смены статуса заказа
AddEventHandler('sale', 'OnOrderStatusChange', function(\Bitrix\Main\Event $event) {
    $order = $event->getParameter('ORDER');
    $newStatus = $event->getParameter('NEW_STATUS');

    if ($newStatus === 'PROCESSING') {
        foreach ($order->getShipmentCollection() as $shipment) {
            if (!$shipment->isSystem()) {
                $deliveryService = $shipment->getDelivery();
                // Тест: проверяем что createShipment возвращает трек-номер
                $result = $deliveryService->createShipment($shipment);
                // result должен содержать tracking_number
            }
        }
    }
});

Трекинг

Тестируем на реальных трек-номерах (у CDEK есть тестовые в документации sandbox) с проверкой обновления поля UF_TRACKING в b_sale_shipment.

# Получить токен
curl -X POST https://api.edu.cdek.ru/v2/oauth/token \
  -d "grant_type=client_credentials&client_id=EMscd6r9JnFiQ3bLoyjJY6eM&client_secret=PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6"

# Рассчитать доставку
curl -X POST https://api.edu.cdek.ru/v2/calculator/tariff \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{"tariff_code":136,"from_location":{"code":44},"to_location":{"code":270},"packages":[{"weight":1000,"length":20,"width":15,"height":10}]}'

Как автоматизировать регрессионное тестирование доставки?

Для регрессионного тестирования расчётов доставки пишут unit-тесты на PHPUnit с мокированием HTTP-клиента. Автоматизированное тестирование лучше ручного в 5 раз по скорости регресса. Оно охватывает 95% сценариев против 70%.

class CdekDeliveryTest extends \PHPUnit\Framework\TestCase
{
    public function testCalculateReturnsNonZeroForValidPackage(): void
    {
        $httpMock = $this->createMock(HttpClient::class);
        $httpMock->method('post')->willReturn($this->getFixture('cdek_tariff_response.json'));

        $service = new CdekDeliveryService(['http_client' => $httpMock]);
        $result = $service->calculate($this->buildShipment(weight: 1000, city: 'SPB'));

        $this->assertGreaterThan(0, $result->getPrice());
        $this->assertNotEmpty($result->getPeriodMin());
    }
}

Сравнение ручного и автоматизированного тестирования

Что входит в работу

• Аудит текущей интеграции и документации
• Написание тестовых сценариев под ваш каталог и службы
• Тестирование расчётов, ПВЗ, создания отправлений, трекинга
• Составление отчёта с найденными ошибками и рекомендациями
• Автоматизация регрессионных тестов (опционально)
• Консультация по исправлению типовых проблем

Сроки и стоимость

Стоимость рассчитывается индивидуально после анализа вашего ТЗ. Мы гарантируем выявление не менее 90% типовых ошибок интеграции. Каждая найденная ошибка экономит компании до 500 000 ₽ на исправлении в продакшне. Свяжитесь с нами для предварительной оценки проекта — получите консультацию по типовым проблемам вашей интеграции. Закажите тестирование сейчас.