Unit-тести на Vitest: впровадження та підтримка фронтенду

Без модульних тестів рефакторинг на фронтенді — це гра в російську рулетку. Упавший компонент у продакшені може коштувати 4–8 годин налагодження, а CI-пайплайн на Jest затягується до 15 хвилин. Перехід на Vitest скорочує час прогону 500 тестів до 5 секунд локально та 2 хвилин у CI. Vitest — сучасний тест-раннер, побудований на Vite: він використовує спільний dev-сервер, нативний ESM та паралельний запуск за замовчуванням. Наш досвід — понад 20 проектів, де ми впроваджували Unit-тести на Vitest, налаштовували пороги покриття та інтегрували CI. Економія на CI-ресурсах може сягати значних сум — десятків тисяч гривень щомісяця.

Як Vitest вирішує проблему повільних тестів?

Без тестів рефакторинг перетворюється на лотерею. Упавший компонент у продакшені — це втрата 4-8 годин на налагодження. Vitest ловить регресії на етапі розробки: гаряча перезагрузка тестів (HMR) спрацьовує за мілісекунди, і ви одразу бачите помилки. Типовий React-компонент покривається 5-10 тестами, які перевіряють рендер з різними пропсами, обробники, стани завантаження та помилки. Налаштувавши Vitest одного разу, ви отримуєте 80% покриття рядків і 70% гілок. Це знижує ймовірність багів у production і прискорює розробку нових функцій.

Чому Vitest швидший за Jest?

Vitest використовує спільний dev-сервер з Vite — це дає приріст швидкості в 4 рази при виконанні 500 тестів. Вбудована підтримка ESM позбавляє від трансформації node_modules, а паралельний запуск за замовчуванням розподіляє навантаження по ядрах процесора. У результаті тести не гальмують розробку, а стають її частиною. Ми спостерігали скорочення часу CI з 12 до 3 хвилин на проектах із 800+ тестами. Вбудована підтримка mock-функцій та spying робить тести простішими та швидшими, ніж у Jest.

"Vitest is a blazing fast unit test framework powered by Vite" — з офіційної документації Vitest (https://vitest.dev).

Як ми налаштовуємо Vitest під ваш проект

Ми починаємо з аудиту поточного стеку. Якщо у вас уже є Jest — адаптуємо конфігурацію. Якщо проект із нуля — створюємо еталонне налаштування. Типовий конфіг виглядає так:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
    plugins: [react()],
    test: {
        environment: 'jsdom',
        globals: true,
        setupFiles: ['./src/test/setup.ts'],
        coverage: {
            provider: 'v8',
            reporter: ['text', 'json', 'html'],
            thresholds: { lines: 80, functions: 80, branches: 70 },
        },
    },
});

// src/test/setup.ts
import '@testing-library/jest-dom';
import { cleanup } from '@testing-library/react';
import { afterEach } from 'vitest';

afterEach(() => cleanup());

Порівняння Vitest і Jest

Що входить у роботу з впровадження Vitest

Ми здаємо проект із усім необхідним:

• Налаштований Vitest із порогами покриття (lines 80%, functions 80%, branches 70%)
• Написані Unit-тести для ключових компонентів та бізнес-логіки (не менше 10 тестів на компонент)
• Міграція з Jest (якщо потрібно) зі збереженням усіх існуючих тестів
• Інтеграція в CI (GitHub Actions / GitLab CI) із звітами про покриття
• Документація щодо запуску тестів та додавання нових
• Навчання команди: 2–3 сесії з написання тестів на Vitest

Порівняння інструментів покриття

Процес впровадження

1. Аудит — оцінюємо поточний код та тести, виявляємо вузькі місця.
2. Налаштування — встановлюємо Vitest, пишемо конфіг, моки та setup-файли.
3. Розробка тестів — покриваємо ключову логіку: утиліти, хуки, компоненти.
4. Міграція (опціонально) — конвертуємо Jest-тести з мінімальними правками.
5. CI-інтеграція — додаємо запуск тестів у пайплайн та пороги покриття.
6. Передача — передаємо документацію та проводимо навчання.

Чому варто довірити впровадження нам

За час роботи ми реалізували понад 20 проектів з Unit-тестами на Vitest. Гарантуємо, що тести будуть стабільними, а не «флакающими». Використовуємо перевірені практики: Vitest — open-source проект з активним співтовариством, і ми стежимо за оновленнями. У типовому React-компоненті покриваються: рендер з різними пропсами, обробники подій, стани (порожній, завантаження, помилка), взаємодія з хуками (useState, useEffect), edge cases (null, undefined, граничні значення). Ми також враховуємо метрики Core Web Vitals, щоб тести не тільки перевіряли логіку, а й не погіршували LCP та INP.

Терміни та вартість

Базове налаштування Vitest + написання першого пакету тестів займає 2–4 дні. Міграція з Jest — до 5 днів залежно від обсягу. Вартість розраховується індивідуально після аудиту. Замовте аудит — і ми підберемо оптимальне рішення. Отримайте консультацію, щоб оцінити ваш проект. Зв'яжіться з нами для деталей.

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

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