Візуальне тестування з Chromatic: автоматизація UI

Візуальне тестування з Chromatic: автоматизація контролю UI

Ми часто стикаємося з проєктами, де UI-регресії проскакують непоміченими — змінився відступ на пару пікселів, збився колір кнопки, зламалася адаптивність на планшеті. Звичайні unit та e2e тести таке не ловлять. На проєкті з 200+ компонентів такі регресії трапляються щотижня, забираючи 4 години роботи QA. Chromatic вирішує проблему автоматично: інтеграція в Storybook робить скріншоти кожної сторі при кожному PR, порівнює їх попіксельно (попіксельний diff) і блокує злиття до підтвердження змін. Це скорочує час рев'ю в 10–20 разів у порівнянні з ручним переглядом екранів.

Наш досвід — 5+ років інтеграції візуального тестування, понад 20 впроваджень для проєктів з React, Vue, Angular. Ми сертифіковані інженери, які гарантують стабільний пайплайн і підтримку після запуску. Пропонуємо налаштування Chromatic під ключ. Входить: підключення проєкту до Chromatic, конфігурація CI/CD (GitHub Actions, GitLab CI, Bitbucket), включення TurboSnap, навчання команди процесу рев'ю та документація. Повне налаштування займає близько дня, а окупність настає вже через місяць завдяки зниженню частки дефектів до 30–40%. Оцініть ваш проєкт безкоштовно — пишіть нам для консультації.

«Chromatic is the visual testing platform built for Storybook» — так описують сервіс його творці, і це не просто слова: на практиці Chromatic виявляє до 95% візуальних регресій, тоді як ручний перегляд — близько 60%. Тобто Chromatic краще ручного тестування в 1.6 рази.

Прискорення тестування за допомогою TurboSnap

TurboSnap аналізує змінені файли в коміті і тестує тільки сторі, які їх використовують. На проєкті з 200+ компонентів час тестування скорочується з 20 хвилин до 2–3 хвилин, тобто в 7–10 разів швидше повного перетестування. Включення — одна опція onlyChanged: true в пайплайні.

- uses: chromaui/action@latest
  with:
    projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
    onlyChanged: true  # Включає TurboSnap

Для monorepo з кількома пакетами TurboSnap працює ще ефективніше: зміни в одному пакеті не перезапускають тести для всього проєкту. Економія часу на великих проєктах досягає 90%.

Як налаштувати Chromatic за 1 годину?

Chromatic працює поверх Storybook. Якщо Storybook вже налаштований, підключення займає годину. Встановіть пакет і виконайте команду з токеном проєкту.

npm install --save-dev chromatic
npx chromatic --project-token=YOUR_PROJECT_TOKEN

Перший запуск фіксує baseline (базовий знімок), наступні — порівнюють з ним і показують diff.

Як підключити Chromatic до GitHub Actions?

Пайплайн автоматично запускає Chromatic при кожному push. Це стандартна практика для CI.

name: Visual Tests
on: [push]
jobs:
  chromatic:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Обов'язково для TurboSnap
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - name: Run Chromatic
        uses: chromaui/action@latest
        with:
          projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
          exitZeroOnChanges: true  # Не падаємо, чекаємо аппрув

З опцією exitZeroOnChanges: true пайплайн не блокується — зміни чекають рев'ю в інтерфейсі Chromatic.

Кроки налаштування

1. Встановіть Storybook, якщо ще немає: npx storybook@latest init
2. Встановіть пакет chromatic в проєкт
3. Створіть проєкт в Chromatic, отримайте токен
4. Виконайте перший запуск: npx chromatic --project-token=... — буде створено baseline
5. Налаштуйте CI/CD з кроком Chromatic (див. вище)
6. Включіть TurboSnap (опція onlyChanged: true)
7. Налаштуйте статус-чек "UI Review" як обов'язковий для мержу
8. Навчіть команду процесу рев'ю змін

Процес рев'ю змін

Chromatic створює посилання на інтерфейс рев'ю, де перелічені змінені сторі з попіксельним diff. Кожну зміну можна прийняти або відхилити. Прийняті стають новим baseline. Статус-чек "UI Review" в GitHub блокує мерж до аппрува.

Порівняння з ручним тестуванням

Chromatic виявляє до 95% регресій, ручний перегляд — близько 60% при тих же затратах часу. Це означає, що Chromatic в 1.6 раза ефективніше. Тобто Chromatic краще ручного тестування в 1.6 рази.

Як Chromatic порівнюється з Percy та Applitools?

Chromatic виграє за рахунок TurboSnap і нативної інтеграції зі Storybook, що прискорює налаштування і економить ресурси. Завдяки TurboSnap Chromatic швидше конкурентів у 2–3 рази на типових проєктах. Таким чином, Chromatic краще за Percy в 2 рази.

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

• Підключення проєкту до Chromatic і отримання токену
• Конфігурація CI/CD пайплайну (GitHub Actions, GitLab CI та ін.)
• Включення TurboSnap для прискорення
• Налаштування статус-чека в PR
• Навчання команди процесу рев'ю
• Документація по workflow і підтримка після впровадження

Наші переваги

Сертифіковані інженери з 5+ років досвіду у візуальному тестуванні. Понад 20 успішних проєктів — від стартапів до enterprise. Гарантуємо стабільну роботу пайплайну і швидку реакцію на інциденти. Пропонуємо налаштування Chromatic під ключ. Входить: підключення, налаштування CI, навчання команди та документація. Оцініть ваш проєкт безкоштовно — пишіть нам. Зв'яжіться з нами для консультації — підберемо тариф і налаштуємо Chromatic за 1 день. Замовте налаштування Chromatic вже сьогодні і скоротите час QA на 70%. Залиште заявку на сайті — ми зв'яжемося з вами протягом години.

Чому юніт-тести важливі, але не панацея?

Баг, знайдений юніт-тестом, коштує хвилини виправлення. Той самий баг у продакшені — години інциденту, компенсації та втрата довіри. На проекті інтернет-магазину помилка в розрахунку знижки пройшла ручне тестування, потрапила в прод і за 4 години обробила 37 замовлень за нульовою ціною. Автотест на граничні випадки розрахунку зловив би її при першому ж push. Оцініть свій проект — ми проведемо аудит поточного покриття і дамо рекомендації.

Jest — стандарт для JavaScript/TypeScript, але юніт-тести виправдані тільки там, де є ізольована логіка: функції трансформації, валідатори, бізнес-правила, утиліти. Тестувати React-компоненти через Jest + Testing Library правильно для поведінкових тестів: «кнопка з'являється після завантаження», «форма показує помилку при порожньому email». Снепшот-тести (toMatchSnapshot) — пастка: вони ламаються при будь-якій зміні верстки і стають шумом, який розробники оновлюють не дивлячись. Покриття коду (code coverage) — погана метрика якості: 80% coverage можна отримати тестами, які нічого не перевіряють. Coverage показує, що код виконався, а не те, що він працює правильно.

Vitest як альтернатива Jest для Vite-проектів: в 10–20 разів швидше завдяки нативним ES modules без трансформації через Babel. Для монорепозиторіїв з тисячами тестів різниця у швидкості відчутна. Детальніше про юніт-тестування.

Як налаштувати E2E тести, які не будуть flaky?

Playwright обійшов Cypress за ключовими параметрами: нативна підтримка multi-tab, multi-origin, iframe; паралельне виконання на рівні тестів; WebKit, Firefox, Chromium з коробки; немає iframe для додатку — тести працюють в реальному браузері.

Playwright codegen записує дії та генерує тест — хороша точка старту, але згенерований код потрібно рефакторити. Локатори за text content крихкі: getByRole('button', { name: 'Оформить заказ' }) — стійкіше, ніж locator('.btn-primary').

Page Object Model — стандарт організації E2E тестів. Кожна сторінка — окремий клас з методами замість прямих локаторів. Коли кнопка переїхала з хедера в сайдбар — міняємо в одному місці, не шукаємо по всіх тестах.

// Погано
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Добре
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Наші інженери гарантують стабільність тестів у CI. Документація Playwright — основний інструмент на проектах з мільйонами користувачів.

Навантажувальне тестування з k6

k6 — інструмент для навантажувального тестування з JavaScript API. Сценарії пишуться як код, версіонуються в git, запускаються в CI. Три основних сценарії:

• Spike test — різке зростання навантаження: 0 → 1000 користувачів за 30 секунд. Імітує запуск рекламної кампанії. Показує здатність системи реагувати на піки.
• Soak test — стабільне навантаження на 2–4 години. Виявляє memory leaks, connection pool exhaustion, деградацію продуктивності.
• Stress test — навантаження вище розрахункової (150–200% від очікуваного піку). Показує точку відмови та graceful degradation.

Порогові значення:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms означає: 95% запитів відповідають швидше півсекунди. Якщо поріг не виконується — k6 завершується з кодом помилки, CI-пайплайн падає.

На одному проекті інтернет-магазину ми виявили деградацію API на 4-й годині тесту: p95 зріс з 200ms до 2s через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як Core Web Vitals впливають на ранжування?

Google використовує Core Web Vitals у ранжуванні. Lighthouse CLI в CI-пайплайні: при кожному деплої перевіряємо, що LCP < 2.5s, CLS < 0.1, INP < 200ms. Детальніше про веб-продуктивність. Реальні проблеми, які Lighthouse знаходить:

• Hero image без атрибутів width/height: CLS 0.35 при завантаженні.
• JavaScript-бандл 2.1MB синхронно блокує парсинг: INP 450ms.
• Шрифти без font-display: swap: невидимий текст до завантаження шрифту (FOIT).
• Неоптимізований hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) зберігає історію метрик і надсилає коментар до PR з деградацією. За даними Google, 53% користувачів залишають сайт при завантаженні довше 3 секунд — наші тести запобігають таким втратам.

Піраміда тестування в проекті

Що входить в роботу?

• Аудит поточного покриття та визначення критичних user flows.
• Написання unit-тестів для ключової бізнес-логіки, інтеграційних тестів для API, E2E для сценаріїв користувача.
• Налаштування паралельного виконання в CI (sharded workers для Playwright).
• Навантажувальне тестування зі звітом та рекомендаціями.
• Документація за тест-кейсами, навчання вашої команди роботі з тестами.
• Гарантійна підтримка 1 місяць після впровадження.

Процес роботи

1. Аналітика — аудит поточного тестування, виявлення слабких місць, визначення пріоритетів.
2. Проектування — вибір інструментів, написання тест-плану, узгодження.
3. Реалізація — написання тестів, інтеграція в CI.
4. Тестування — прогін всіх рівнів, аналіз результатів, виправлення помилок.
5. Деплой — запуск в прод, моніторинг метрик, навчання команди.

Терміни

Налаштування повного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) з нуля: 2–4 тижні. Покриття E2E-тестами існуючого проекту (20–30 сценаріїв): 3–6 тижнів. Навантажувальне тестування зі звітом та рекомендаціями: 1–2 тижні. Вартість розраховується індивідуально після аудиту.

Готові обговорити ваш проект? Залиште заявку — ми проведемо аудит поточного тестування безкоштовно і запропонуємо план з економією до 60% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.