From 4 Hours to 15 Minutes: Automating Regression for 1C-Bitrix

Bitrix core updates roll out every two weeks. After each update, manual regression testing takes 4–8 hours. Integration with 1C via CommerceML adds extra risk. The tight coupling and global state interdependency necessitate meticulous bootstrap configuration and dependency isolation. We automate regression to be at least 24 times faster: tests complete in 10–15 minutes instead of four hours. With over 8 years of experience, we have automated regression for more than 30 projects. Without automation, a project can lose up to 20% of its budget on testing—that's roughly $2000 per month or $5000 annually for a typical project. With automation, the monthly testing cost drops to under $100, yielding savings of over $1,900 per month.

Why Bitrix Requires a Special Testing Approach

The main challenge is the monolithic architecture with tight coupling between components and heavy reliance on global state. All components depend on global state: \Bitrix\Main\Application::getInstance(), \CMain, $DB. Unit tests cannot run without initializing the kernel. This requires a special infrastructure. Second, frequent updates—each update can break 1C integration or custom solutions. Third, isolation complexity. Without automation, every new release is stressful. The codebase exhibits high cyclomatic complexity and side effects, making manual testing error-prone. We solve these issues with a proven tool stack.

Tool Stack

For Bitrix projects, we use a combination of the following tools:

Order a test system development today—it pays off after two updates.

How to Set Up PHPUnit for Bitrix

The core problem of unit-testing Bitrix is that code depends on global state. You cannot run a test without initializing the kernel.

The solution is to load the kernel in the test bootstrap file:

// tests/bootstrap.php
$_SERVER['DOCUMENT_ROOT'] = dirname(__DIR__);
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
define('BX_WITH_ON_AFTER_EPILOG', false);

require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

phpunit.xml:

<phpunit bootstrap="tests/bootstrap.php">
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/unit</directory>
        </testsuite>
    </testsuites>
</phpunit>

What to Test with Unit Tests

Business logic isolated in classes without direct kernel dependencies:

class ArticleResolverTest extends TestCase
{
    public function testResolveValidArticle(): void
    {
        $resolver = new ArticleResolver($this->createMockRepository());
        $result = $resolver->resolve('ABC-123', CATALOG_IBLOCK_ID);
        $this->assertSame(456, $result->getSkuId());
    }

    public function testResolveUnknownArticleReturnsNull(): void
    {
        $resolver = new ArticleResolver($this->createEmptyRepository());
        $this->assertNull($resolver->resolve('UNKNOWN', CATALOG_IBLOCK_ID));
    }
}

Key pattern: dependency injection instead of direct calls to static Bitrix methods—this makes code testable. Savings on regression can reach 80%.

Functional Tests with Codeception

Codeception with the Bitrix module allows testing HTTP scenarios without a browser:

// tests/functional/OrderCheckoutCest.php
class OrderCheckoutCest
{
    public function addToCartAndCheckout(FunctionalTester $I): void
    {
        $I->amOnPage('/catalog/product-slug/');
        $I->click('Добавить в корзину');
        $I->seeInDatabase('b_sale_basket', ['PRODUCT_ID' => 123]);

        $I->amOnPage('/order/');
        $I->fillField('NAME', 'Тест Тестов');
        $I->fillField('EMAIL', '[email protected]');
        $I->click('Оформить заказ');
        $I->seeInDatabase('b_sale_order', ['STATUS_ID' => 'N']);
    }
}

E2E Tests with Playwright

For critical user paths, we use e2e tests that run a real browser:

// tests/e2e/checkout.spec.js
test('full checkout flow', async ({ page }) => {
    await page.goto('/catalog/product-slug/');
    await page.click('.add-to-cart-btn');
    await expect(page.locator('.cart-count')).toHaveText('1');

    await page.goto('/order/');
    await page.fill('[name="NAME"]', 'Test User');
    await page.fill('[name="EMAIL"]', '[email protected]');
    await page.click('.submit-order-btn');
    await expect(page).toHaveURL(/\/order\/success\//);
});

How to Integrate Tests into CI/CD?

Tests run automatically on every push. We use GitHub Actions or GitLab CI. Setup takes 2–4 hours. Result: each commit passes checks—unit tests in 30 seconds, functional in 3 minutes, e2e in 5–10 minutes. On failure, the build stops and the developer gets notified.

According to 1C-Bitrix documentation, the test environment must be isolated from production. Therefore, all tests run on a copy of the database with test data.

Comparison of Manual vs Automated Testing

Automation pays off within 2–3 months, and automated testing is 24 times faster than manual—a real breakthrough in efficiency.

Typical Stages of Test System Development

1. Code and architecture audit (1–2 days): Identify modules to cover.
2. Bootstrap and infrastructure setup (1–2 days): Create working test environment.
3. Refactoring for dependency injection (3–5 days): Make code testable.
4. Unit tests for business logic (5–10 days): Build stable unit test suite.
5. Functional tests (Codeception) (3–5 days): Verify HTTP scenarios.
6. E2E tests (Playwright) (3–5 days): Cover critical paths.
7. CI/CD integration (1–2 days): Automate run on push.
8. Documentation and training (1–2 days): Team ready to maintain.

What's Included in Test System Development

• Audit of current code and identification of testable modules.
• Setup of PHPUnit bootstrap environment for loading Bitrix in test mode.
• Code refactoring for dependency injection and testability.
• Writing unit tests for key business logic.
• Setting up Codeception for functional HTTP scenario tests.
• E2E tests with Playwright for critical user paths.
• Integration into CI/CD (GitHub Actions, GitLab CI).
• Documentation and team training.
• Access to test environment and post-deployment support.

We guarantee test stability on core updates. Certified specialists with 5+ years of experience and over 30 Bitrix automation projects. The actual cost savings are tangible: a typical project spending $5000 annually on manual testing can reduce that to under $1200 after automation—saving $3800 each year.

Ready to automate testing for your Bitrix project? Contact us—we'll evaluate your project for free and propose a turnkey solution. Get a consultation right now. Automated testing is not just faster; it's 24 times more efficient than manual testing, giving you a competitive edge.

Duplicate Products on Page 3: A Bug That Goes to Production

A real case: an online store with pagination through bitrix:catalog.section duplicates products on page three after every second visit. Cache clearing helps for a day, then the duplicates return. Root cause: a custom sort handler collides with PAGEN_1, and under a specific filter combination CIBlockElement::GetList returns identical IDs. Code review missed it; only testing caught it. We build QA for 1C-Bitrix projects that catches such bugs before they hit production: manual functional, automated E2E, load, and acceptance testing. With over a decade of Bitrix experience, we have a library of typical pitfalls and test scenarios that prevent these issues from the start.

How Does a Standard Bitrix Project Break Without Dedicated Testing?

1C-Bitrix is not a landing page. Behind the frontend lie dozens of modules, external integrations, and non‑obvious dependencies. A discount change in sale.discount breaks a promo code in sale.basket.discount — the discount module is one of the most fragile in the platform. Interchange with 1C via catalog.import.1c or REST fails when property mapping is off, resulting in products without price or stock. Core updates — bitrix:main updated, a custom component uses the deprecated CModule::IncludeModule. Without regression testing, every deployment is Russian roulette. Cross‑browser: sale.order.ajax renders differently in Safari and Chrome; the “Place Order” button can move off‑screen on an iPhone. These are not edge cases — they are daily realities for Bitrix teams.

What Does Functional Testing Cover?

We check every business scenario — not just “works or doesn’t work”, but all boundary cases.

Catalog (catalog.section, catalog.element)

• Smart filter catalog.smart.filter: all property combinations, reset, result counting. Filters by SKUs break most often.
• Sorting + pagination — the duplicate bug described above.
• Comparison via catalog.compare.list — add, remove, display differences.
• Quick view — modal window, cart from modal.

Cart and Order (sale.basket.basket, sale.order.ajax)

• Adding from catalog, product page, quick order.
• Discounts: by quantity, by amount, by coupon, cumulative. Discount intersection — at least eight test combinations.
• Delivery calculation: handlers sale.delivery.services, cost, time, pickup points on map.
• Payment: sale.paysystem — processing, handling declines, refunds.
• Order placement: email via main.mail.event, CRM recording, transmission to 1C via sale.export.1c.

Personal Account (sale.personal.section)

• Registration, authorization, password recovery — including Cyrillic email edge cases.
• Order history, repeat order.
• Subscriptions, bonus program.

Forms and Search

• form.result.new / iblock.element.add.form — submission, validation, file fields.
• search.page — relevance, morphology, typo handling via search.title.

Why Is Regression Testing Critical for Bitrix?

After every deployment we verify that nothing previously working is broken.

• Smoke tests — main page loads, catalog shows products, order completes. 5 minutes, run after every deploy. If smoke fails — roll back immediately.
• Regression suite — 40–80 test cases covering main scenarios before every release.
• Visual testing — screenshot comparison (Percy or Playwright). A button shifted 20px, font changed after update — test shows the diff.
• Module checklists — structured lists for sale, catalog, iblock, search. Each module has its own checklist.

What Happens During Load Testing?

The question is not “will the site handle it” but at how many concurrent users catalog.section starts returning 500 errors.

Tools:

• k6 — JavaScript scripting.
• Apache JMeter — classic, for complex scenarios with cookie authorization.
• Yandex.Tank — real‑time visualization, integration with Overload.

Output: peak RPS, response times by percentiles p50/p95/p99, bottlenecks (CPU, RAM, MySQL slow queries on b_iblock_element, file cache). Recommendations: which index to add, which query to rewrite with D7 ORM, where to enable composite cache.

What Deliverables Do You Receive After Testing?

• Test plan with scope, priorities, and quality criteria.
• Test case suite — functional, regression, load.
• Defect report in a tracker (Jira/YouTrack) with severity classification.
• Auto tests (Playwright/Cypress) — basic smoke suite for CI/CD.
• Load testing protocol with graphs and recommendations.
• Acceptance certificate after UAT — confirming readiness for launch.

After delivery, we provide free consultation for a month — answering questions on test improvements and process adaptation. Contact us to receive a full package of documents and auto tests.

Cross‑Browser Testing

We test where buyers actually are. Statistics from your Metrica are more important than general market data.

Minimum set:

• Chrome (last 2 versions) — main traffic.
• Safari on iOS — critical for mobile checkout, sale.order.ajax often behaves unpredictably.
• Yandex.Browser — significant share in Russia, Chromium‑based but with extension quirks.
• Samsung Internet — mobile Android, often forgotten.

Devices:

• Desktop: 1920×1080, 1366×768.
• iPhone: 375×812, 390×844 — checkout must be verified.
• Android: 360×800, 412×915.

Tools: BrowserStack for real devices, Playwright for automation on Chromium/Firefox/WebKit.

Automation

Playwright — primary choice for E2E on Bitrix:

• Cross‑browser: Chromium, Firefox, WebKit.
• Parallel execution, automatic waits.
• Works well with dynamic forms sale.order.ajax.
• Supports mobile viewports and geolocation.

Cypress:

• Runs in browser — more stable for SPA‑like interfaces.
• Excellent visual runner for debugging.
• Limitation: only Chromium‑based browsers.

PHPUnit for custom code:

• Unit tests for custom Bitrix components and modules.
• Tests business logic without frontend dependency.
• Integration with CI/CD — GitLab CI, GitHub Actions.

UAT – Acceptance Testing

Final check with the client on a staging environment with real data:

• Jointly compile a list of critical scenarios — 15–20 key customer paths, not 200 test cases.
• Staging with a copy of the production database (anonymized personal data).
• Quick bug tracking — Jira/YouTrack, prioritization by severity.
• Acceptance protocol — document with results, signatures, and launch readiness.

Order UAT support and we guarantee a release without surprises.

QA Process – Integrated, Not Tacked On

1. Requirements analysis — QA participates in task discussions, catches ambiguities. “Does the discount apply to the product or the order?” — such a question upfront saves two days of debugging.
2. Test cases before development — scenarios ready before the first line of code.
3. Code review — checks for typical Bitrix mistakes: uncleared component cache, direct SQL queries instead of ORM, missing $USER‑>IsAuthorized() check.
4. Functional → regression → deploy.
5. Post‑release monitoring — errors in bitrix/error.log, metrics in Metrica, alerts for 500 errors.

We have been working with Bitrix for over 10 years and have tested more than 300 projects of various scales — from small online stores to corporate portals with 1C and Bitrix24 integration.

Timelines

Testing cost is calculated individually for your project. Get a free consultation — we will assess the scope within one business day and provide a preliminary estimate and test plan. Contact us to discuss your project and schedule a call.