Чому E2E-тестування критичне для Бітрікс-проєктів?
Після кожного оновлення модуля, шаблону або API-інтеграції хтось вручну перевіряє кошик, оформлення замовлення та особистий кабінет. Процес займає 2–3 години, але все одно пропускає регресії: жоден тестувальник за один прогін не охопить п'ять браузерів, мобільні в'юпорти та авторизацію через соцмережі. У нас за плечима понад 50 проєктів на Бітрікс — приблизно в третині випадків реліз затримувався саме через пропущену регресію, виявлену в останній момент. E2E-тести вирішують цю проблему автоматично: вони проганяються за 15–20 хвилин, стабільно знаходять ті самі кейси, які людина пропускає.
Як ми це робимо?
Налаштовуємо тестове середовище, обираємо інструмент, пишемо Page Object Model для ключових компонентів та інтегруємо прогін у ваш CI/CD. Працюємо під ключ — від аудиту поточної архітектури до передачі документації та навчання команди.
Playwright vs Cypress: що обрати для Бітрікс?
| Критерій | Playwright | Cypress |
|---|---|---|
| Підтримка браузерів | Chromium, Firefox, WebKit | Тільки Chromium та похідні |
| Мобільні в'юпорти | Емуляція пристроїв (iPhone, Pixel та ін.) | Обмежена емуляція |
| Робота з кількома вкладками | Нативно | Не підтримується |
| Мережеве перехоплення | Є (route, waitForResponse) | Є, але складніше |
| Інтеграція з CI/CD | Проста, вбудований репортер | Вимагає додаткових плагінів |
| Швидкість виконання | Висока (паралельний запуск) | Середня |
Playwright — оптимальний вибір для Бітрікс-проєктів. Він підтримує всі браузери в одному запуску, працює headless та headful, має потужний локатор API, який не ламається при зміні DOM. Вбудована емуляція мобільних пристроїв та мережеве перехоплення — те, що потрібно для тестування sale.order.ajax з його асинхронністю.
Cypress хороший для SPA, але для багатосторінкових Бітрікс-сайтів його обмеження (один origin, відсутність нативної роботи з кількома вкладками) створюють проблеми. У наших проєктах ми використовуємо Playwright у 9 випадках з 10.
Інфраструктура тестового середовища
Тестове середовище — обов'язково окрема база даних з фіксованими даними. Жодних тестів на продакшені. Ми розгортаємо копію сайту з відомими характеристиками: каталог з 50–100 товарів, кілька типів платників, налаштовані способи доставки та оплати. Мінімальна структура репозиторію:
tests/ e2e/ fixtures/ # JSON з тестовими даними pages/ # Page Object Model specs/ # сценарії playwright.config.ts // playwright.config.ts import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ testDir: './tests/e2e/specs', timeout: 30_000, retries: process.env.CI ? 2 : 0, use: { baseURL: process.env.TEST_BASE_URL || 'https://test.shop.example.com', trace: 'on-first-retry', screenshot: 'only-on-failure', }, projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] } }, { name: 'mobile', use: { ...devices['iPhone 13'] } }, ], }); Page Object Model для Бітрікс
Стандартні компоненти bitrix:sale.order.ajax, bitrix:sale.basket.basket та bitrix:system.auth.form мають стійкі CSS-класи. Page Object ізолює локатори від тестів — якщо в новій версії шаблону змінюється верстка, правимо один файл, а не всі сценарії.
// tests/e2e/pages/CartPage.ts import { Page, Locator } from '@playwright/test'; export class CartPage { readonly page: Page; readonly checkoutButton: Locator; readonly totalPrice: Locator; constructor(page: Page) { this.page = page; this.checkoutButton = page.locator('.basket-checkout-btn'); this.totalPrice = page.locator('.basket-coupon-block-total-price-current'); } async goto() { await this.page.goto('/personal/cart/'); } async applyPromocode(code: string) { await this.page.fill('.basket-coupon-field-input', code); await this.page.click('.basket-coupon-apply-btn'); await this.page.waitForResponse(resp => resp.url().includes('ajax_basket') && resp.status() === 200 ); } } Ключові сценарії
Додавання до кошика та оформлення замовлення:
// tests/e2e/specs/checkout.spec.ts import { test, expect } from '@playwright/test'; import { CartPage } from '../pages/CartPage'; test('checkout flow', async ({ page }) => { // Додаємо товар зі сторінки каталогу await page.goto('/catalog/electronics/headphones/sennheiser-hd-599/'); await page.click('.catalog-element-offer-set-item:first-child'); // вибір SKU await page.click('.btn-buy'); await expect(page.locator('.bx-basket-count')).toContainText('1'); // Перехід до кошика const cart = new CartPage(page); await cart.goto(); await expect(cart.totalPrice).toBeVisible(); // Оформлення await cart.checkoutButton.click(); await page.fill('#order-name', 'Іван Іванов'); await page.fill('#order-email', '[email protected]'); await page.fill('#order-phone', '+380123456789'); await page.click('#pay-system-1'); // вибір способу оплати await Promise.all([ page.waitForURL(/\/order\/success\//), page.click('.btn-checkout-submit'), ]); await expect(page.locator('.sale-order-detail-result')).toBeVisible(); }); Авторизація та особистий кабінет:
test('login and account access', async ({ page }) => { await page.goto('/personal/login/'); await page.fill('#USER_LOGIN', '[email protected]'); await page.fill('#USER_PASSWORD', 'testpassword123'); await page.click('.login-btn'); await expect(page).toHaveURL(/\/personal\//); await expect(page.locator('.personal-user-name')).toContainText('Іван'); }); Інтеграція в CI/CD
Налаштовуємо прогін тестів при кожному пуші в main/staging. У разі падіння артефакти (скріншоти, трейси) зберігаються для аналізу. Приклад конфігу GitHub Actions:
# .github/workflows/e2e.yml name: E2E Tests on: push: branches: [main, staging] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 20 } - run: npm ci - run: npx playwright install --with-deps chromium - run: npx playwright test env: TEST_BASE_URL: ${{ secrets.TEST_BASE_URL }} - uses: actions/upload-artifact@v4 if: failure() with: name: playwright-report path: playwright-report/ Що входить у налаштування E2E (що ми віддаємо)
- Аудит поточної архітектури: які компоненти використовуються, як реалізована асинхронність, які сценарії критичні.
- Проєктування тестового покриття: узгодження списку сценаріїв з вашою командою.
- Написання Page Object Model для 5–10 ключових компонентів.
- Реалізація 15–30 тестових сценаріїв (кошик, checkout, авторизація, фільтрація, промокоди, особистий кабінет).
- Налаштування CI/CD прогону (GitHub Actions / GitLab CI / Jenkins).
- Документація з запуску та підтримки тестів.
- Навчання команди: 2–3 годинний воркшоп з додавання нових сценаріїв.
Які сценарії покривати в першу чергу?
| Сценарій | Пріоритет | Компоненти Бітрікс |
|---|---|---|
| Додавання до кошика + checkout | Критичний | sale.basket.basket, sale.order.ajax |
| Авторизація / реєстрація | Критичний | system.auth.form |
| Пошук + фільтрація каталогу | Високий | search.title, catalog.smart.filter |
| Застосування промокоду | Високий | sale.basket.basket.coupon |
| Особистий кабінет (історія замовлень) | Середній | sale.personal.order.list |
Стабільність тестів — головне завдання. Ми використовуємо waitForResponse замість waitForTimeout, локатори по data-testid там, де стандартні CSS-класи змінюються при оновленнях шаблону. При нестабільних тестах проблема майже завжди в асинхронності Бітрікс AJAX, а не в Playwright.
Наш досвід та гарантії
Ми — сертифіковані партнери 1С-Бітрікс з досвідом понад 5 років. За цей час реалізували E2E-тестування для 20+ проєктів різної складності — від невеликих інтернет-магазинів до корпоративних порталів на Бітрікс24. Гарантуємо стабільність тестів: після передачі вони не падають на порожніх змінах. Якщо виникають питання — безкоштовно консультуємо протягом місяця після здачі.
Як замовити налаштування?
Оцінимо ваш проєкт за 1–2 робочих дні. Для цього потрібен доступ до репозиторію та тестового середовища. Зв'яжіться з нами — розкажемо, які сценарії покриємо в першу чергу і скільки це займе часу за строками.