Testing 1C-Bitrix integrations with delivery services

Testing 1C-Bitrix Integrations with Delivery Services

Delivery service integration in Bitrix is not just a pretty pickup point selection form. It is a chain: cost calculation → order creation in the carrier's system → waybill printing → tracking. Any link in that chain can break silently, with no visible error on the site. A customer places an order, a manager goes to create a shipment — and discovers that the address failed CDEK validation or the DHL pickup point is already closed. Delivery integration testing is specifically aimed at catching these scenarios before production.

Delivery Integration Architecture in Bitrix

Delivery services are connected through the sale module as delivery handlers (\Bitrix\Sale\Delivery\Services\Base). Each service has a separate class implementing:

• calculateConcrete() — cost calculation
• createShipment() — creating a shipment in the external system (if implemented)
• getTrackingInfo() — retrieving tracking status

Custom handlers are placed in /local/php_interface/include/sale_delivery/. Standard delivery service modules (CDEK, DHL, DPD, Boxberry, PickPoint) are installed from the Marketplace.

What to Test

Delivery cost calculation — the first and most common failure point. Check:

1. Correct calculation for different product dimensions (products must have WEIGHT, WIDTH, HEIGHT, DEPTH filled in the catalog)
2. Behavior when some cart items have no dimensions
3. Correctness of delivery zones — the Moscow rate must not be applied to Vladivostok
4. Calculation caching: a repeat request for the same cart must return a cached result without hitting the external API

// Check delivery calculation cache
$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);
}

Pickup point selection — CDEK, Boxberry, PickPoint widgets load a map via JS. Test:

• Widget loading in all target browsers
• Correct passing of the selected pickup point to the checkout form
• Retention of the selected pickup point on page reload
• Behavior when JS is unavailable (graceful degradation)

Shipment creation — verify that the order is correctly registered in the delivery service's system when the status changes in Bitrix:

// Order status change event handler
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();
                // Test: verify that createShipment returns a tracking number
                $result = $deliveryService->createShipment($shipment);
                // result must contain tracking_number
            }
        }
    }
});

Case Study: CDEK + Bitrix

A common problem when testing the official CDEK module: cost calculation returns 0 or an empty tariff array. Causes in order of frequency:

1. Product dimensions not filled in — CDEK API v2 returns 400 when weight/length are missing; the module silently returns 0
2. Wrong city code — CDEK uses its own city codes (not KLADR, not FIAS); verify via POST /v2/location/cities
3. Tariff not activated in the contract — attempting to calculate tariff 136 (Parcel depot-to-depot) without the service enabled returns an authorization error, not 403
4. Sandbox vs Production — CDEK test credentials: EMscd6r9JnFiQ3bLoyjJY6eM, PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6

For checking raw requests to the CDEK v2 API in the test environment:

# Get token
curl -X POST https://api.edu.cdek.ru/v2/oauth/token \
  -d "grant_type=client_credentials&client_id=EMscd6r9JnFiQ3bLoyjJY6eM&client_secret=PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6"

# Calculate delivery
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}]}'

If the raw request succeeds but the Bitrix module does not work — the problem is in the module adapter.

Tracking is tested using real tracking numbers (CDEK provides test tracking numbers in the sandbox documentation), verifying that the UF_TRACKING field in b_sale_shipment is updated.

Automation

For regression testing of delivery calculations, write PHPUnit unit tests with HTTP client mocking:

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

Timelines