Розробка Visual Regression тестів для сайту (Chromatic)

Верстка зламалася через невидиму зміну padding — дизайнер помітив через тиждень

Ручна перевірка кожної сторінки після кожного коміту — це години роботи. Одна помилка в CSS може коштувати десятки тисяч гривень на виправлення та втрату клієнтів. Visual Regression тестування з Chromatic вирішує це: автоматичне порівняння скріншотів на кожному PR. Ми налаштовуємо це під ключ за 1–2 тижні, і ваш проект більше не страждає від випадкових регресій. Зв’яжіться з нами, щоб обговорити деталі вашого проекту та отримати консультацію.

Як візуальне регресійне тестування з Chromatic захищає UI?

Chromatic робить знімок кожного story з Storybook, порівнює з еталоном (baseline) і просить розробника схвалити або відхилити зміни. Це виключає випадкові правки, які ламають верстку. Наприклад, якщо хтось ненавмисно змінить padding у CSS, Chromatic покаже різницю в пікселях. Згідно з документацією Chromatic, точність порівняння сягає 99.9%. За нашими оцінками, автоматизація візуального тестування економить до 80 000 гривень на місяць на проекті з 5 розробниками.

Приклад з практики

Налаштування Storybook і написання stories

Встановлюємо Chromatic і Storybook:

npm install -D chromatic @storybook/react
npx storybook init  # якщо Storybook ще не налаштований

Кожен компонент отримує свої stories — стани, які потрібно перевірити. Приклад для кнопки:

// components/Button/Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';

const meta: Meta<typeof Button> = {
  component: Button,
  parameters: {
    // Затримка перед скріншотом для анімацій
    chromatic: { delay: 300 },
  },
};

export default meta;
type Story = StoryObj<typeof Button>;

export const Primary: Story = {
  args: { variant: 'primary', children: 'Зберегти' },
};

export const Secondary: Story = {
  args: { variant: 'secondary', children: 'Скасувати' },
};

export const Loading: Story = {
  args: { loading: true, children: 'Завантаження' },
};

export const Disabled: Story = {
  args: { disabled: true, children: 'Недоступно' },
};

Щоб зняти кілька viewport або виключити анімації, додайте параметри в окрему story:

export const ResponsiveCard: Story = {
  parameters: {
    chromatic: {
      viewports: [375, 768, 1280],
    },
  },
};

Запобігання хибним спрацьовуванням

Хибні спрацьовування виникають через анімації, шрифти або випадкові дані. Використовуйте параметр chromatic.delay для очікування завершення анімацій, disableSnapshot для виключення нестабільних компонентів. Також допомагає pauseAnimationAtEnd: true — зупиняє анімацію на останньому кадрі. Налаштування viewports допомагає виключити нерелевантні роздільні здатності.

Параметри для тонкого налаштування скріншотів

Інтеграція з CI/CD: GitHub Actions

Додаємо workflow, який запускає Chromatic при кожному push:

# .github/workflows/chromatic.yml
name: Visual Tests

on: push

jobs:
  chromatic:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with: { node-version: 20 }

      - run: npm ci

      - name: Run Chromatic
        uses: chromaui/action@latest
        with:
          projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
          exitZeroOnChanges: true
          exitOnceUploaded: false

Workflow рев’ю:

1. Pull request змінює компонент.
2. Chromatic запускається в CI, знаходить зміни.
3. Посилання на рев’ю з’являється в PR-коментарі.
4. Розробник в UI Chromatic: схвалити або відхилити зміни.
5. Після схвалення — новий baseline.

Як TurboSnap прискорює тестування?

Chromatic аналізує змінені файли через Git і тестує тільки ті stories, які залежать від змінених компонентів. На великому проекті це скорочує час на 80%. Chromatic тестує в 2 рази швидше за Percy завдяки вбудованому TurboSnap.

- name: Run Chromatic with TurboSnap
  uses: chromaui/action@latest
  with:
    projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
    onlyChanged: true

Порівняння Chromatic з альтернативами

Що входить у налаштування під ключ

• Встановлення та конфігурація Storybook (якщо відсутній).
• Написання stories для 20–50 ключових компонентів.
• Налаштування CI/CD для автоматичного запуску Chromatic.
• Навчання команди роботі з UI рев’ю.
• Документація щодо процесу візуального тестування.
• Документація та доступи до проекту Chromatic.
• Гарантія безперебійної роботи протягом місяця після здачі.

Терміни реалізації:

• Налаштування Storybook + Chromatic: 1 день.
• Написання stories для 20–30 компонентів: 3–5 днів.
• Повне покриття design system: 1–2 тижні.

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

1. Аналіз поточного проекту та вибір компонентів для покриття.
2. Встановлення Storybook і Chromatic, налаштування базового workflow.
3. Написання stories для ключових компонентів (з урахуванням станів і viewport).
4. Інтеграція з CI/CD та налаштування TurboSnap.
5. Тестування та відлагодження хибних спрацьовувань.
6. Документування та навчання команди.
7. Гарантійна підтримка місяць після здачі.

Чому варто обрати нас

Ми — команда з 5+ роками досвіду в автоматизації тестування. Реалізували понад 50 проектів з візуального тестування, включаючи інтеграцію з Chromatic, Percy і Applitools. Наші інженери сертифіковані в Storybook і Chromatic. Надаємо гарантію на всі роботи та безкоштовну підтримку протягом місяця.

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

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

Баг, знайдений юніт-тестом, коштує хвилини виправлення. Той самий баг у продакшені — години інциденту, компенсації та втрата довіри. На проекті інтернет-магазину помилка в розрахунку знижки пройшла ручне тестування, потрапила в прод і за 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% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.