Разработка E2E-тестов для сайта на Cypress

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка E2E-тестов для сайта на Cypress
Средний
~5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Разработка E2E-тестов для сайта (Cypress)

Сбой в критическом сценарии пользователя — потерянная конверсия и подпорченная репутация. Ручные регрессионные тесты отнимают часы перед каждым релизом, а найти баг после деплоя — дорого. Мы решаем эту проблему: внедряем сквозные тесты на Cypress, которые проверяют каждый пользовательский путь от клика до бэкенда. Автоматизация регрессии снижает расходы на ручное тестирование и ускоряет выпуск релизов. В отличие от Selenium или Puppeteer, Cypress запускается в том же цикле событий, что и приложение. Это даёт встроенный time-travel debugger, автоматическое ожидание элементов без sleep() и полный контроль над сетевыми запросами через cy.intercept(). Мы используем его для проектов на React, Vue, Angular и даже на чистом JavaScript.

Какие проблемы решает E2E-тестирование на Cypress?

  • Флейковые тесты — главная боль E2E. Cypress автоматически ожидает элементы и не использует sleep(), что устраняет нестабильность.
  • Долгий прогон регрессии — при параллельном запуске на CI время сокращается с часов до минут.
  • Сложность отладки — time-travel позволяет пошагово просмотреть каждый шаг и понять, что пошло не так.

Кейс: тестирование многошагового заказа для интернет-магазина

Для одного клиента мы покрыли флоу оформления заказа с интеграцией Stripe. Написали 15 тестов, которые проверяли успешную оплату, отказ карты, таймаут и возврат к корзине. Использовали cy.intercept() для мока ответов Stripe, что сделало тесты полностью детерминированными. Результат: время регрессии сократилось с 4 часов до 15 минут, а частота багов на проде снизилась на 30%.

Почему Cypress — лучший выбор для E2E-тестирования?

Cypress позволяет писать тесты в 2–3 раза быстрее, чем Selenium, благодаря встроенному автоматическому ожиданию и отсутствию WebDriver. Он интегрируется напрямую с фреймворками, поддерживает перехват всех сетевых запросов и даёт возможность путешествовать во времени — видеть каждый шаг теста в интерфейсе. Это снижает время отладки флейковых тестов на 40%.

Что мы покрываем тестами?

  • Аутентификация и сессии: логин, регистрация, восстановление пароля — с моками API для независимости от среды.
  • Основные user flows: оформление заказа, добавление товара в корзину, создание сущностей — полная цепочка от UI до базы.
  • Навигация и маршрутизация: проверка редиректов, хлебных крошек, 404 страниц.
  • Обработка ошибок: недоступность сервиса, некорректные данные, сетевые таймауты — чтобы пользователь не видел белый экран.

Мы проверяем не только happy path, но и граничные случаи: пустые корзины, некорректные купоны, истечение сессии. Это обеспечивает пользовательский опыт на грани отказоустойчивости.

Как мы реализуем E2E-тесты на Cypress?

Установка и конфигурация

npm install -D cypress
npx cypress open  # первый запуск — создаёт структуру директорий

Структура проекта

cypress/
├── e2e/          # тестовые спецификации
├── fixtures/     # статические данные для тестов
├── support/
│   ├── commands.ts   # кастомные команды
│   └── e2e.ts        # глобальная конфигурация
└── cypress.config.ts

Базовый тест: авторизация

// cypress/e2e/auth/login.cy.ts
describe('Login', () => {
    beforeEach(() => {
        cy.visit('/login');
    });

    it('successfully logs in with valid credentials', () => {
        cy.get('[data-cy="email-input"]').type('[email protected]');
        cy.get('[data-cy="password-input"]').type('password123');
        cy.get('[data-cy="login-btn"]').click();

        cy.url().should('include', '/dashboard');
        cy.get('[data-cy="user-name"]').should('contain', 'Иван');
    });

    it('shows error on invalid credentials', () => {
        cy.get('[data-cy="email-input"]').type('[email protected]');
        cy.get('[data-cy="password-input"]').type('wrongpass');
        cy.get('[data-cy="login-btn"]').click();

        cy.get('[data-cy="error-message"]')
            .should('be.visible')
            .and('contain', 'Неверный email или пароль');
    });
});

Перехват API-запросов

// Мок API — тест не зависит от бэкенда
it('displays products from API', () => {
    cy.intercept('GET', '/api/products*', {
        fixture: 'products.json',
        statusCode: 200,
    }).as('getProducts');

    cy.visit('/products');
    cy.wait('@getProducts');

    cy.get('[data-cy="product-card"]').should('have.length', 10);
});

// Проверка запроса
it('sends correct payload on form submit', () => {
    cy.intercept('POST', '/api/orders', (req) => {
        expect(req.body).to.deep.include({ productId: 1, quantity: 2 });
        req.reply({ statusCode: 201, body: { orderId: 100 } });
    }).as('createOrder');

    // ... действия
    cy.wait('@createOrder');
    cy.get('[data-cy="success-message"]').should('be.visible');
});

Как интегрировать Cypress в CI/CD?

Настраиваем запуск тестов в GitHub Actions, GitLab CI или Jenkins. Для параллельного запуска используем Cypress Dashboard или GitHub Actions matrix strategy. Это сокращает время прогона 40 тестов до 3–4 минут. Также настраивается запись результатов для анализа флейковых тестов.

Сравнение подходов к E2E-тестированию

Критерий Cypress Selenium Playwright
Установка npm i -D cypress Требует WebDriver npm i @playwright/test
Скорость выполнения Высокая (встроенный wait) Средняя (явные ожидания) Высокая (авто-ожидание)
Поддержка браузеров Chrome, Firefox, Edge Все основные Все основные
Time-travel debugger Встроенный Нет Нет
Перехват сети cy.intercept() Требуется прокси page.route()
Документация и сообщество Огромное Огромное Растущее

Что входит в работу?

  1. Аудит текущего UI — определяем ключевые сценарии и точки стабильности.
  2. Разработка фреймворка — настраиваем Cypress, пишем кастомные команды и фикстуры.
  3. Покрытие тестами — от 20 до 80 сценариев в зависимости от сложности проекта.
  4. Интеграция CI/CD — настраиваем запуск в GitHub Actions, GitLab CI или Jenkins.
  5. Документация и обучение — передаём команде инструкции по запуску и обновлению тестов.
  6. Гарантия стабильности — два цикла прогона на вашем стенде и фиксация flaky-тестов.

Сроки реализации

Объём тестов Срок
20–40 сценариев (типовой сайт) 5–8 дней
40–80 сценариев (сложный UI) 10–14 дней
Дополнительная кросс-браузерность +2–3 дня

Стоимость рассчитывается индивидуально после оценки проекта.

Мы гарантируем, что тесты будут стабильны: используем data-cy атрибуты, моким внешние API через cy.intercept() и избегаем sleep(). Это делает тесты детерминированными и снижает flaky-прогоны. В результате вы получаете надёжное покрытие, которое окупается за счёт стабильности релизов и снижения времени на регрессию. Наш опыт — более 5 лет и 30+ проектов с E2E-тестированием на Cypress.

Свяжитесь с нами — получите консультацию по вашему проекту. Оценим объём, сроки и приступим к внедрению. Закажите внедрение E2E-тестов уже сегодня — это окупится стабильностью релизов и спокойствием команды.

Почему юнит-тесты важны, но не панацея?

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

Процесс работы

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

Сроки

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

Готовы обсудить ваш проект? Оставьте заявку — мы проведём аудит текущего тестирования бесплатно и предложим план с экономией до 60% времени на инциденты. Получите консультацию по тестированию веб-приложений — напишите нам.