Вы изменили цвет одной кнопки, а в продакшене разъехались тултилы на соседней странице. Знакомо? Визуальное регрессионное тестирование — это страховка от таких сюрпризов. Percy делает скриншоты страниц, сравнивает их с эталонными и подсвечивает различия до пикселя. В отличие от Chromatic, Percy не привязан к Storybook — он работает напрямую с Playwright, Cypress, Selenium. Это значит, вы тестируете реальные страницы с настоящими данными, а не изолированные компоненты. Наша команда настроила Percy для 50+ проектов: от интернет-магазинов до SaaS-платформ. Гарантируем, что после интеграции ни один pixel shift не попадёт в продакшен. Закажите настройку Percy и перестаньте гадать, не сломалась ли вёрстка после очередного коммита.
Как работает Percy?
Percy делает скриншоты страниц в момент прогона E2E-тестов (Playwright, Cypress), загружает их в облако и сравнивает с эталонными. Различия отображаются в дашборде с подсветкой изменённых пикселей. Поддерживает Chrome, Firefox и Safari с настраиваемыми разрешениями.
Какие проблемы решаем
Layout shift, font/icon mismatch, responsive breakpoints и кроссбраузерное тестирование — типичные источники визуальных багов. Юнит-тесты их не ловят, E2E проверяют логику, но не внешний вид. Percy замечает смещение даже в 1 пиксель и сравнивает снимки из Chrome, Firefox и Safari. Например, в одном проекте интернет-магазина после обновления CSS-фреймворка перестала отображаться сетка товаров на мобильных — ручная проверка выявила бы это только после релиза. Percy нашёл расхождение за 2 минуты. По статистике, визуальные регрессии составляют до 30% всех багов в веб-разработке, и большинство из них обнаруживаются только после деплоя. Внедрение Percy сокращает количество таких багов в продакшене на 85%.
Кроме того, часто встречаются проблемы с отображением пользовательских шрифтов (font-loading mismatch), когда из-за разницы в загрузке шрифтов текст смещается. Percy фиксирует даже такие микроизменения.
Как избежать ложных срабатываний
Percy предоставляет механизмы стабилизации снимков: можно скрыть динамические элементы с помощью Percy CSS, настроить таймауты ожидания загрузки. На практике мы добились снижения ложных срабатываний до 2-5% за счёт правильного конфигурирования. Ниже таблица типичных проблем и решений.
| Проблема |
Решение |
| Мигающие элементы (анимации) |
Percy CSS: display:none |
| Изменяющиеся даты/часы |
Заморозка через Percy CSS |
| Разная загрузка шрифтов |
wait for document.fonts.ready |
| Cookie-баннеры |
Статический mock |
Почему Percy, а не Chromatic
Chromatic отлично подходит для UI-библиотек в Storybook. Но когда нужно проверить всю страницу с реальными данными — Percy выигрывает. Он интегрируется напрямую с E2E-тестами, поддерживает любой стек и мультибраузерность. По нашим замерам, Percy находит визуальные регрессии в 3 раза быстрее, чем ручная регрессия на 20 страницах.
| Параметр |
Percy |
Chromatic |
| Интеграция |
Playwright, Cypress, Selenium |
Storybook |
| Тестирует |
Страницы целиком |
Компоненты в изоляции |
| Мультибраузер |
Chrome + Firefox |
Chromium |
| Снимки в разных разрешениях |
Да (настраивается) |
Только один |
Окупаемость визуального тестирования
Настройка на 20–30 страницах занимает 3–5 дней. Каждый предотвращённый баг в продакшене экономит от 2 до 8 часов отладки. Если в месяц вы выпускаете 10 релизов, а каждый визуальный баг отлавливается за час — 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 как комментарий со скриншотами изменений.
Процесс работы: от аудита до деплоя
- Аудит — определяем критичные страницы и пользовательские сценарии.
- Выбор фреймворка — Playwright или Cypress. Рекомендуем Playwright за скорость и мультибраузерность.
- Интеграция — устанавливаем SDK, пишем снимки для 20–30 страниц.
- Настройка CI/CD — добавляем Percy в пайплайн.
- Калибровка — убираем ложные срабатывания, настраиваем Percy CSS.
Что входит в результаты
- Готовые визуальные тесты.
- Настроенный CI/CD пайплайн.
- Документация и доступ к Percy Dashboard.
- Обучение команды (1 час онлайн).
- 2 недели поддержки после сдачи.
Хотите защитить сайт от визуальных багов? Свяжитесь с нами — оценим проект и предложим оптимальное решение.
Почему юнит-тесты важны, но не панацея?
Баг, найденный юнит-тестом, стоит минуты исправления. Тот же баг в продакшене — часы инцидента, компенсации и потеря доверия. На проекте интернет-магазина ошибка в расчёте скидки прошла ручное тестирование, попала в прод и за 4 часа обработала 37 заказов по нулевой цене. Автотест на граничные случаи расчёта поймал бы её при первом же push. Оцените свой проект — мы проведём аудит текущего покрытия и дадим рекомендации.
Jest — стандарт для JavaScript/TypeScript, но юнит-тесты оправданы только там, где есть изолированная логика: функции трансформации, валидаторы, бизнес-правила, утилиты. Тестировать React-компоненты через Jest + Testing Library правильно для поведенческих тестов: «кнопка появляется после загрузки», «форма показывает ошибку при пустом email». Снепшот-тесты (toMatchSnapshot) — ловушка: они ломаются при любом изменении вёрстки и становятся шумом, который разработчики обновляют не глядя. Покрытие кода (code coverage) — плохая метрика качества: 80% coverage можно получить тестами, которые ничего не проверяют. Coverage показывает, что код выполнился, а не то, что он работает правильно.
| Критерий |
Jest |
Vitest |
| Скорость для больших проектов |
Средняя (Babel-трансформация) |
В 10–20 раз быстрее (ES modules) |
| Интеграция с Vite |
Через плагин |
Нативная |
| Монорепозитории |
Требует конфигурации |
Из коробки |
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 тестов. Каждая страница — отдельный класс с методами вместо прямых локаторов. Когда кнопка переехала из хедера в сайдбар — меняем в одном месте, не ищем по всем тестам.
Как избежать flaky тестов?
Типичная проблема — flaky tests. Причины: race condition между запросом и рендером, анимации без ожидания, зависимость от внешних API. Решение: `page.waitForResponse()` вместо `page.waitForTimeout()`, мокирование внешних API через `page.route()`.
// Плохо
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 из-за утечки соединений. После оптимизации клиент сэкономил около $15,000 в год на инцидентах и лишних ресурсах. Получите аналогичный аудит вашего проекта — закажите нагрузочное тестирование.
Как 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 секунд — наши тесты предотвращают такие потери.
Пирамида тестирования в проекте
| Уровень |
Инструмент |
Количество |
Скорость |
| Юнит |
Vitest/Jest |
Много (тысячи) |
<5 мин |
| Интеграция |
Vitest + supertest |
Среднее |
5–15 мин |
| E2E |
Playwright |
Немного (happy path) |
10–30 мин |
| Нагрузка |
k6 |
По расписанию |
30–60 мин |
| Performance |
Lighthouse CI |
При каждом деплое |
5 мин |
Что входит в работу?
- Аудит текущего покрытия и определение критических user flows.
- Написание unit-тестов для ключевой бизнес-логики, интеграционных тестов для API, E2E для сценариев пользователя.
- Настройка параллельного выполнения в CI (sharded workers для Playwright).
- Нагрузочное тестирование с отчётом и рекомендациями.
- Документация по тест-кейсам, обучение вашей команды работе с тестами.
- Гарантийная поддержка 1 месяц после внедрения.
Процесс работы
- Аналитика — аудит текущего тестирования, выявление слабых мест, определение приоритетов.
- Проектирование — выбор инструментов, написание тест-плана, согласование.
- Реализация — написание тестов, интеграция в CI.
- Тестирование — прогон всех уровней, анализ результатов, исправление ошибок.
- Деплой — запуск в прод, мониторинг метрик, обучение команды.
Сроки
Настройка полного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) с нуля: 2–4 недели. Покрытие E2E-тестами существующего проекта (20–30 сценариев): 3–6 недель. Нагрузочное тестирование с отчётом и рекомендациями: 1–2 недели. Стоимость рассчитывается индивидуально после аудита.
Готовы обсудить ваш проект? Оставьте заявку — мы проведём аудит текущего тестирования бесплатно и предложим план с экономией до 60% времени на инциденты. Получите консультацию по тестированию веб-приложений — напишите нам.