Regression testing of a 1C-Bitrix website

Regression Testing of a 1C-Bitrix Website

Updating the Bitrix core from version 23.x to 24.x, installing a new module from the Marketplace, upgrading PHP from 8.1 to 8.2 — any of these actions can silently break something that has been working for months. Regression testing is a systematic check that after changes, existing functionality continues to work. On Bitrix projects it is especially important due to frequent core updates (releases come out weekly) and the abundance of extension points via events and agents.

What Breaks During Bitrix Updates

Practice reveals several consistent regression patterns.

Deprecated core methods. Bitrix systematically marks methods as deprecated and removes them after a few versions. The problem — legacy code in /local/ written against the old D6 API:

// Deprecated D6 code (breaks on updates)
$el = new CIBlockElement();
$el->GetList([], ['IBLOCK_ID' => 5], false, false, ['ID', 'NAME']);

// Current D7 ORM
\Bitrix\Iblock\ElementTable::getList([
    'filter' => ['=IBLOCK_ID' => 5],
    'select' => ['ID', 'NAME'],
]);

Template conflicts. After updating Bitrix components (sale, catalog modules), templates in /local/templates/ may no longer match the new component logic. A classic example: changes to the $arResult structure in the bitrix:catalog.section component.

Agents and scheduler. After a core update, the b_agent table sometimes loses active agent flags or the call signature changes. Check after every major update:

SELECT name, active, last_exec, next_exec, agent
FROM b_agent
WHERE active = 'Y'
ORDER BY next_exec;

Regression Suite Structure

The regression suite for a Bitrix project is organized into levels:

Smoke tests (5–10 minutes) — minimal set, run after every deployment:

• Homepage loads (HTTP 200)
• Adding a product to the cart
• Existing user login
• Order placement (up to the payment step)
• Admin panel opens

Basic regression (2–4 hours) — run before every release:

• Full order placement flow with each delivery and payment type
• Smart filter with multiple parameters
• User account: history, profile editing
• Main forms: callback, subscription, contacts

Full regression (1–2 days) — for major core updates or significant codebase changes.

Case Study: Core Update 23.700 → 24.100

Project — an online building materials store, ~15,000 SKU, CDEK + Russian Post, YooKassa + Sber. After the core update, the regression run identified:

1. Smart filter stopped working — cause: the bitrix:catalog.smart.filter component parameter format changed; the template in /local/templates/ used the removed arResult['FORM_ATTRIBUTES'] property
2. Order cancellation email notifications were duplicated — the OnOrderStatusChange event was fired twice due to new behavior in \Bitrix\Sale\Order::save()
3. 1C sync agent hung — the new PHP 8.2 threw a TypeError when passing null to strpos(); the agent silently crashed while b_agent showed it as "active"

All three issues were caught before deployment to production precisely because the regression run was executed on a staging environment with a production database dump.

Tooling and Automation

For automating regression tests on Bitrix projects, the recommended approach is:

Playwright for UI tests with screenshot capture on failure:

// playwright.config.js
module.exports = {
    use: {
        baseURL: 'https://staging.shop.com',
        screenshot: 'only-on-failure',
        video: 'on-first-retry',
    },
    retries: 1,
};

PHPUnit + BitrixTestCase for testing components and helpers. Run in CI/CD (GitHub Actions, GitLab CI) on every push to main:

# .gitlab-ci.yml
regression:
  stage: test
  script:
    - php vendor/bin/phpunit --testsuite=regression
    - npx playwright test --reporter=html
  artifacts:
    when: on_failure
    paths:
      - playwright-report/

Visual regression testing with @playwright/test + playwright-visual-comparisons plugin — comparing screenshots of key pages before and after an update.

Timelines