Тестування інтеграцій 1С-Бітрікс зі службами доставки

Тестування інтеграцій 1С-Бітрікс із службами доставки

Інтеграція зі службами доставки в Бітрікс — це не лише красива форма вибору пункту видачі. Це ланцюжок: розрахунок вартості → створення замовлення в особистому кабінеті служби → друк накладної → трекінг. Будь-яка ланка може ламатися тихо, без явних помилок на сайті. Покупець оформлює замовлення, менеджер іде створювати відправлення — і тут з'ясовується, що адреса не пройшла валідацію в CDEK або ПВЗ DHL вже зачинений. Тестування інтеграцій доставки спрямоване саме на виявлення таких сценаріїв до продакшну.

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

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

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

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

Що тестувати

Розрахунок вартості доставки — перша і найчастіша точка відмови. Перевіряють:

1. Коректність розрахунку для різних габаритів товару (потрібні товари із заповненими WEIGHT, WIDTH, HEIGHT, DEPTH у каталозі)
2. Роботу при відсутності габаритів у частини товарів у кошику
3. Коректність зон доставки — тариф для Києва не повинен застосовуватися до Львова
4. Кешування розрахунків: повторний запит того самого кошика повинен повертати результат із кешу, не звертаючись до зовнішнього 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 + Бітрікс

Типова проблема при тестуванні офіційного модуля CDEK: розрахунок вартості повертає 0 або порожній масив тарифів. Причини за частотою:

1. Не заповнені габарити товарів — CDEK API v2 при відсутності weight/length повертає 400, модуль мовчки повертає 0
2. Неправильний код міста — CDEK використовує власні коди міст (не КЛАДР, не ФІАС); перевіряють через POST /v2/location/cities
3. Тариф не активований у договорі — спроба розрахувати тариф 136 (Посилка склад-склад) при непідключеній послузі дає помилку авторизації, а не 403
4. Sandbox vs Production — тестові credentials CDEK: EMscd6r9JnFiQ3bLoyjJY6eM, PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6

Для перевірки raw-запитів до API CDEK v2 у тестовому оточенні:

# Отримати токен
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}]}'

Якщо raw-запит проходить, а модуль Бітрікс не працює — проблема в адаптері модуля.

Трекінг тестують на реальних трек-номерах (у CDEK є тестові трек-номери в документації sandbox) із перевіркою оновлення поля UF_TRACKING у b_sale_shipment.

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

Для регресійного тестування розрахунків доставки пишуть unit-тести на PHPUnit із мокуванням HTTP-клієнта:

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());
    }
}

Терміни