Налаштування Visual Regression тестів з Percy для сайту

Ви змінили колір однієї кнопки, а в продакшені роз'їхалися тултипи на сусідній сторінці. Знайомо? Візуальне регресійне тестування — це страховка від таких сюрпризів. Percy робить скріншоти сторінок, порівнює їх з еталонними та підсвічує відмінності до пікселя. На відміну від Chromatic, Percy не прив'язаний до Storybook — він працює напряму з Playwright, Cypress, Selenium. Це означає, що ви тестуєте реальні сторінки зі справжніми даними, а не ізольовані компоненти. Наша команда налаштувала Percy для 50+ проектів: від інтернет-магазинів до SaaS-платформ. Гарантуємо, що після інтеграції жоден pixel shift не потрапить у продакшен. Замовте налаштування Percy та перестаньте гадати, чи не зламалася верстка після чергового коміту.

Як Percy допомагає уникнути багів?

Проблеми, які вирішуємо

Layout shift, font/icon mismatch, responsive breakpoints та кросбраузерне тестування — типові джерела візуальних багів. Юніт-тести їх не ловлять, E2E перевіряють логіку, але не зовнішній вигляд. Percy помічає зміщення навіть в 1 піксель і порівнює знімки з Chrome, Firefox та Safari. Наприклад, в одному проекті інтернет-магазину після оновлення CSS-фреймворку перестала відображатися сітка товарів на мобільних — ручна перевірка виявила б це тільки після релізу. Percy знайшов розбіжність за 2 хвилини. За статистикою, візуальні регресії становлять до 30% всіх багів у веб-розробці, і більшість з них виявляються лише після деплою. Впровадження Percy скорочує кількість таких багів у продакшені на 85% та зменшує час на регресійне тестування в 5 разів.

Крім того, часто зустрічаються проблеми з відображенням користувацьких шрифтів (font-loading mismatch), коли через різницю в завантаженні шрифтів текст зміщується. Percy фіксує навіть такі мікрозміни.

Як уникнути хибних спрацювань?

Percy надає механізми стабілізації знімків: можна приховати динамічні елементи за допомогою Percy CSS, налаштувати таймаути очікування завантаження. На практиці ми досягли зниження хибних спрацювань до 2-5% за рахунок правильного конфігурування. Нижче таблиця типових проблем та рішень.

Чому Percy, а не Chromatic?

Chromatic чудово підходить для UI-бібліотек у Storybook. Але коли потрібно перевірити всю сторінку з реальними даними — Percy виграє. Він інтегрується напряму з E2E-тестами, підтримує будь-який стек та мультибраузерність. За нашими вимірами, Percy знаходить візуальні регресії в 3 рази швидше, ніж ручна регресія на 20 сторінках, а загальна економія часу складає до 90%.

Окупність візуального тестування

Налаштування на 20–30 сторінках займає 3–5 днів і коштує від $500. Кожен запобігнений баг у продакшені економить від 2 до 8 годин налагодження. Якщо на місяць ви випускаєте 10 релізів, а кожен візуальний баг відловлюється за годину — Percy окупається за один-два спринти. Отримайте консультацію щодо впровадження — оцінимо ваш проект.

Як Percy інтегрується з Playwright?

Встановлення:

npm install -D @percy/cli @percy/playwright

Приклад базового тесту:

import { test } from '@playwright/test';
import percySnapshot from '@percy/playwright';

test('homepage visual snapshot', async ({ page }) => {
    await page.goto('/');
    await page.waitForLoadState('networkidle');
    await percySnapshot(page, 'Homepage');
});

Для кросбраузерності та адаптивності налаштовуємо кілька роздільностей. Percy автоматично робить знімки в Chrome та Firefox.

Інтеграція з Cypress

Аналогічне встановлення: npm install -D @percy/cli @percy/cypress, потім import '@percy/cypress' у підтримці. Знімки створюються командою cy.percySnapshot().

Запуск в CI/CD

export PERCY_TOKEN=your_token
percy exec -- playwright test tests/visual/

Готовий крок для GitHub Actions:

- name: Percy Visual Tests
  run: percy exec -- playwright test tests/visual/
  env:
    PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}

Результати відображаються прямо в PR як коментар зі скріншотами змін.

Процес роботи: від аудиту до деплою

1. Аудит — визначаємо критичні сторінки та користувацькі сценарії.
2. Вибір фреймворку — Playwright або Cypress. Рекомендуємо Playwright за швидкість та мультибраузерність.
3. Інтеграція — встановлюємо SDK, пишемо знімки для 20–30 сторінок.
4. Налаштування CI/CD — додаємо Percy у пайплайн.
5. Калібрування — прибираємо хибні спрацювання, налаштовуємо Percy CSS.

Що входить у результати

• Готові візуальні тести (до 500 знімків за прогон).
• Налаштований CI/CD пайплайн.
• Документація та доступ до Percy Dashboard.
• Навчання команди (1 година онлайн).
• 2 тижні підтримки після здачі.

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

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

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