Розробка 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(). Як зазначено в документації, Cypress дозволяє писати тести в 2 рази швидше, ніж Selenium, завдяки вбудованому автоматичному очікуванню. Ми використовуємо його для проєктів на React, Vue, Angular та навіть на чистому JavaScript. Наш досвід — 10 років та 40+ проєктів з E2E-тестуванням. Вартість впровадження для типового сайту — від $2000, що окупається за 2–3 місяці за рахунок зниження витрат на регресію.

Які проблеми вирішує 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 дні

Вартість розраховується індивідуально після оцінки проєкту. Наприклад, для сайту з 5 ключовими сценаріями вартість стартує від $2000.

Ми гарантуємо, що тести будуть стабільні: використовуємо data-cy атрибути, мокаємо зовнішні API через cy.intercept() та уникаємо sleep(). Це робить тести детермінованими та знижує flaky-прогони. У результаті ви отримуєте надійне покриття, яке окупається завдяки стабільності релізів та зниженню часу на регресію. Наш досвід — понад 10 років та 40+ проєктів з 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 через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як 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 хв
Продуктивність 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% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.