Налаштування Codeception-тестів для 1С-Бітрікс

Налаштування Codeception-тестів для 1С-Бітрікс

Ми стикалися з ситуаціями, коли інтернет-магазин на Бітрікс працював роками без жодного автотесту. Кожне оновлення каталогу або платіжного модуля перетворювалося на ручну перевірку сотень сценаріїв. Клієнти скаржилися на баги в кошику, а розробники боялися змінювати legacy-код. Рішення — впровадити Codeception. Це PHP-фреймворк, який об'єднує unit, functional та acceptance (E2E) тести в одному інструменті. Для Бітрікс він особливо зручний: можна писати functional-тести, що перевіряють PHP-логіку без браузера, та acceptance-тести через WebDriver — все в одному стеку, з одними хелперами та єдиним конфігом.

Чому Codeception для Бітрікс?

Чому саме Codeception, а не класичний PHPUnit? PHPUnit чудово підходить для unit-тестів, але для інтеграційних та acceptance-сценаріїв він вимагає написання додаткової інфраструктури. Codeception надає готові модулі: Db для перевірок бази даних, WebDriver для браузера, PHPBrowser для емуляції HTTP. А головне — модульну архітектуру, в яку ми вбудовуємо власний хелпер для Бітрікс. Цей хелпер ініціалізує інфоблоки, кошик, замовлення через Sale API. Порівняння: один functional-тест на Codeception виконується за 2 хвилини замість 30 хвилин ручної перевірки — в 15 разів швидше. Наша практика показує, що регресійне тестування скорочується на 30-50% після впровадження.

Що входить у налаштування?

Ми віддаємо готовий результат, який можна одразу запустити:

• Конфігурація codeception.yml з трьома суїтами: acceptance, functional, unit.
• Хелпер Bitrix.php для ініціалізації середовища Бітрікс, авторизації користувача та роботи з кошиком/замовленнями через CSale API.
• Набір базових тестів: перевірка авторизації, додавання товару в кошик, створення замовлення.
• Інтеграція з CI/CD (GitLab CI / GitHub Actions) — приклад .gitlab-ci.yml.
• Документація щодо запуску та додавання нових тестів.
• Консультація команди з підтримки тестів протягом 2 тижнів після здачі.

Як Codeception інтегрується з CI/CD?

Ми налаштовуємо запуск тестів у вашому середовищі безперервної інтеграції. Для GitLab CI додається джоба, яка запускає vendor/bin/codecept run після деплою на тестовий стенд. Приклад конфігурації:

# .gitlab-ci.yml
codeception:
  stage: test
  script:
    - composer install --no-progress
    - cp .env.testing .env
    - php vendor/bin/codecept run
  only:
    - develop

Для GitHub Actions аналогічно. Тести виконуються в headless-режимі, без реального браузера для functional-суїти, та з WebDriver для acceptance. Інтеграція займає не більше дня та гарантує, що кожен пуш перевіряється автоматично.

Як ми налаштовуємо Codeception?

Процес складається з п'яти етапів. На першому ми аналізуємо ваш проєкт: версію Бітрікс, структуру каталогу, використовувані модулі (sale, catalog, iblock). Потім встановлюємо пакети через Composer та налаштовуємо codeception.yml. Найважливіший етап — написання хелпера для Бітрікс. Він має коректно підключати пролог, уникати конфліктів з сесіями та статичними файлами. Ми використовуємо константи NO_KEEP_STATISTIC, NOT_CHECK_PERMISSIONS, BX_WITH_ON_AFTER_EPILOG — це типові рішення з документації Бітрікс. Потім пишемо кілька тестів на критичний функціонал: каталог, кошик, оформлення замовлення. Фінальний етап — інтеграція з CI/CD, щоб тести запускалися автоматично при кожному пуші.

Приклад: функціональний тест замовлення

Ось як виглядає functional-тест на створення замовлення через Sale API. Він використовує хелпер для авторизації та додавання товару в кошик:

// tests/Functional/OrderCest.php
namespace Tests\Functional;

use Tests\Support\FunctionalTester;

class OrderCest
{
    public function _before(FunctionalTester $I): void
    {
        // Очищаємо кошик перед кожним тестом
        $I->executeQuery('DELETE FROM b_sale_basket WHERE FUSER_ID = ?', [1]);
    }

    public function addItemAndCreateOrder(FunctionalTester $I): void
    {
        // Додаємо товар у кошик через хелпер
        $I->loginAs('testuser', 'testpassword');
        $count = $I->addProductToCart(42, 2); // товар ID=42, 2 штуки
        $I->assertEquals(1, $count, 'У кошику має бути 1 товар');

        // Створюємо замовлення через Sale API
        $I->executeCustomAction(function () {
            \Bitrix\Main\Loader::includeModule('sale');

            $basket  = \Bitrix\Sale\Basket::loadItemsForFUser(1, 's1');
            $order   = \Bitrix\Sale\Order::create('s1', 1); // сайт, користувач
            $order->setBasket($basket);
            $order->setField('CURRENCY', 'RUB');

            $propertyCollection = $order->getPropertyCollection();
            $prop = $propertyCollection->getPayerName();
            $prop?->setValue('Тестовий Користувач');

            $result = $order->save();
            return $result;
        }, function ($result) use ($I) {
            $I->assertTrue($result->isSuccess(), implode(', ', $result->getErrorMessages()));
        });

        // Перевіряємо, що замовлення створено в базі
        $I->seeInDatabase('b_sale_order', [
            'USER_ID'  => 1,
            'CURRENCY' => 'RUB',
            'STATUS_ID' => 'N',
        ]);
    }
}

Acceptance-тест через WebDriver

Для перевірки UI використовуємо WebDriver з Chrome у headless-режимі. Приклад фільтрації за брендом у каталозі:

// tests/Acceptance/CatalogCest.php
namespace Tests\Acceptance;

use Tests\Support\AcceptanceTester;

class CatalogCest
{
    public function filterByBrandShowsCorrectProducts(AcceptanceTester $I): void
    {
        $I->amOnPage('/catalog/tools/');
        $I->waitForElement('.catalog-filter', 10);

        // Застосовуємо фільтр за брендом
        $I->checkOption('[data-filter="brand"][value="bosch"]');
        $I->waitForElementNotVisible('.catalog-loading', 10);

        // Перевіряємо URL
        $I->seeInCurrentUrl('brand=bosch');

        // Перевіряємо, що всі картки — Bosch
        $I->seeNumberOfElementsGreaterThan('.product-card', 0);
        $brands = $I->grabMultiple('.product-brand');
        foreach ($brands as $brand) {
            $I->assertEquals('Bosch', $brand);
        }
    }
}

Порівняння типів тестів

Строки та процес

Наші інженери мають 5+ років досвіду роботи з Бітрікс та Codeception. За цей час ми реалізували тестування для 30+ проєктів — від невеликих інтернет-магазинів до великих торгових порталів з навантаженням 50 000 товарів. Ми гарантуємо, що тести проходять у вашому середовищі без доопрацювань, і надаємо 2 тижні безкоштовної підтримки після здачі.

Хочете назавжди забути про ручний регрес? Зв'яжіться з нами — оцінимо проєкт і запропонуємо план впровадження за 1 день. Замовте налаштування Codeception та отримайте надійний фундамент для автоматизації тестування.

Тестування сайтів на 1С-Бітрікс

CIBlockElement::GetList і пагінація — баг, який живе роками

Класичний кейс: на сайті каталог із пагінацією через компонент bitrix:catalog.section. Замовник скаржиться — на третій сторінці дублюються товари. Лізеш у кеш компонента, чистиш — начебто ок. Через день знову. Виявляється, кастомне сортування конфліктує з параметром PAGEN_1, і при певній комбінації фільтрів CIBlockElement::GetList повертає ті самі ID. Такі штуки ловляться тільки тестуванням — не код-рев'ю, не «подивився очима».

Зламана пагінація, некоректний розрахунок знижок, помилки інтеграції з 1С — кожен з цих багів коштує бізнесу реальних грошей. Ми знаємо, як їх знайти і виправити до того, як вони вплинуть на продажі. Наша команда має понад 10 років досвіду з Бітрікс і понад 50 успішних QA-проєктів. Ми вибудовуємо QA-процес під проєкти на 1С-Бітрікс: ручне функціональне, автоматизовані E2E, навантажувальне та приймальне тестування.

Чому сайти на 1С-Бітрікс потребують професійного тестування?

Проєкти на 1С-Бітрікс — не лендінги. Під капотом — десятки модулів, інтеграції та неочевидні залежності:

• Ланцюжки в бізнес-логіці — виправив розрахунок знижок у sale.discount, а промокод через sale.basket.discount перестав застосовуватися. Модуль знижок у Бітріксі — один із найкрихкіших: правила пріоритетів, перетини, накопичувальні програми. Одна правка — каскад збоїв.
• Інтеграція з 1С — обмін через catalog.import.1c або REST. Збій у маппінгу властивостей інфоблоку — і на сайті товар без ціни або з нульовим залишком. Розсинхронізація замовлень — втрачені продажі.
• Оновлення ядра — bitrix:main оновився, а кастомний компонент використовував deprecated-метод CModule::IncludeModule з нестандартними параметрами. Без регресії — російська рулетка.
• Мультибраузерність — bitrix:sale.order.ajax рендерить форми по-різному в Safari і Chrome. Кнопка «Оформити замовлення» на iPhone може з'їхати за межі екрана.

Як функціональне тестування вирішує типові проблеми?

Перевіряємо кожен бізнес-сценарій. Не «працює-не працює», а всі граничні випадки.

Каталог (компоненти catalog.section, catalog.element)

• Розумний фільтр catalog.smart.filter: усі комбінації властивостей, скидання, підрахунок результатів. Особливо — фільтри за торговими пропозиціями (SKU), вони ламаються найчастіше.
• Сортування + пагінація — той самий баг із дублями.
• Порівняння через catalog.compare.list — додавання, видалення, відображення відмінностей.
• Швидкий перегляд — модальне вікно, кошик із модалки.

Кошик і замовлення (sale.basket.basket, sale.order.ajax)

• Додавання з каталогу, з картки, швидке замовлення.
• Знижки: за кількістю, за сумою, за купоном, за накопичувальною. Перетин знижок — окремий тест-кейс, мінімум 8 комбінацій.
• Розрахунок доставки: обробники sale.delivery.services, вартість, терміни, ПВЗ на карті.
• Оплата: sale.paysystem — проходження платежу, обробка відхилень, повернення.
• Формування замовлення: email через main.mail.event, запис у CRM, передача в 1С через sale.export.1c.

Особистий кабінет (sale.personal.section)

• Реєстрація, авторизація, відновлення пароля — включно з edge-case із кириличним email.
• Історія замовлень, повторне замовлення.
• Підписки, бонусна програма.

Форми та пошук

• form.result.new / iblock.element.add.form — відправка, валідація, файлові поля.
• search.page — релевантність, морфологія, обробка помилок через search.title.

Регресійне тестування: як ми запобігаємо помилкам після оновлень

Після кожного деплою ми перевіряємо, чи не зламали те, що працювало.

• Smoke-тести — головна відкривається, каталог віддає товари, замовлення проходить до кінця. 5 хвилин, запускаємо після кожного деплою. Якщо smoke впав — відкочуємо, не розбираючись.
• Регресійний набір — 40–80 тест-кейсів за основними сценаріями. Перед кожним релізом.
• Візуальне тестування — порівняння скріншотів через Percy або Playwright. Кнопка з'їхала на 20px, шрифт змінився після оновлення — тест покаже diff.
• Чек-листи за модулями — структуровані списки для sale, catalog, iblock, search. Кожен модуль — свій чек-лист.

Як визначити вузькі місця продуктивності магазину на Бітрікс?

Ми моделюємо навантаження, щоб зрозуміти, при якому RPS catalog.section почне віддавати 500-ку. Використовуємо реалістичні профілі на основі вашої аналітики.

Профіль навантаження для магазину на Бітрікс:

Інструменти: k6 (JavaScript-сценарії для кошика та чекауту), Apache JMeter (складні сценарії з cookie-авторизацією), Yandex.Tank (візуалізація в реальному часі). На виході — максимальний RPS, час відгуку за перцентилями p50/p95/p99, вузькі місця (CPU, RAM, MySQL slow queries на b_iblock_element, файловий кеш). Конкретні рекомендації: який індекс додати, який запит переписати на D7 ORM, де ввімкнути композитний кеш.

У проєкті з 100 000 товарами додавання індекса на b_iblock_element_property.IBLOCK_ELEMENT_ID скоротило час виконання фільтра з 8 секунд до 0.3 секунди — ми знайшли це саме під час навантажувального тестування.

Автоматизоване, кросбраузерне та приймальне тестування

Кросбраузерність перевіряємо там, де реально сидять покупці. Статистика з Метрики конкретного проєкту важливіша за загальноринкові дані. Мінімальний набір: Chrome (останні 2 версії), Safari на iOS, Яндекс.Браузер, Samsung Internet. Пристрої: Desktop 1920×1080 та 1366×768, iPhone 375×812 та 390×844 (обов'язково чекаут), Android 360×800 та 412×915. Інструменти: BrowserStack для реальних пристроїв, Playwright для автоматизації в Chromium/Firefox/WebKit.

Автоматизація базується на Playwright — кросбраузерність, паралельний запуск, автоматичні очікування, добре працює з динамічними формами sale.order.ajax. У порівнянні з ручним тестуванням, автоматизація скорочує час виконання регресії втричі. PHPUnit використовуємо для модульних тестів кастомних компонентів і бізнес-логіки — інтеграція з CI/CD (GitLab CI, GitHub Actions). Тестовий набір із 50 сценаріїв виконується за 15 хвилин замість годин ручної перевірки.

Фінальна перевірка (UAT) проводиться із замовником на staging з копією продової бази. Спільно складаємо 15–20 ключових шляхів покупця, фіксуємо баги в Jira/YouTrack, оформляємо протокол приймання.

QA-процес: як ми вбудовуємо тестування в розробку

Тестування не приклеюється наприкінці — воно стартує з аналізу вимог.

1. Аналіз вимог — QA бере участь в обговоренні завдань, ловить неоднозначності. «Знижка застосовується до товару чи до замовлення?» — таке питання на старті економить два дні відладки.
2. Тест-кейси до розробки — сценарії готові до першого рядка коду.
3. Code review — перевірка на типові помилки Бітрікса: неочищений кеш компонентів, прямі SQL-запити замість ORM, відсутність перевірки $USER->IsAuthorized().
4. Функціональне → регресійне → деплой.
5. Моніторинг після релізу — помилки в bitrix/error.log, метрики в аналітиці, алерти по 500-м.

Закажіть тестування сьогодні — і ми підготуємо тест-план за 2 дні.

Терміни та вартість тестування

Що входить у роботу: детальний тест-план із чек-листами за модулями, автоматизований набір E2E-тестів (Playwright/Cypress) під ваш стек, звіт із результатами, скріншотами помилок і рекомендаціями, інтеграція тестів у ваш CI/CD (GitLab CI, GitHub Actions, Bitbucket Pipelines), супровід UAT — до трьох ітерацій виправлень без додаткової оплати, документація процесу тестування для вашої команди.

Баг на продакшені — це не тільки вартість виправлення. Середнє виправлення критичного дефекту коштує від 20 000 грн, а втрати від зламаного кошика за вихідні на проєкті з оборотом 5 млн/міс можуть сягати 400 000 грн. Інвестиція в тестування — це страховка вашого бізнесу.

Зв'яжіться з нами, щоб отримати комерційну пропозицію та детальний план тестування для вашого проєкту.