Розробка Unit-тестів для фронтенду (Jest)

Ви запускаєте npm test, а 15 тестів падають через нестабільні моки або неправильну конфігурацію. Знайома ситуація? Ми допомагаємо налагодити надійне unit-тестування: налаштовуємо Jest, підключаємо правильні утиліти та покриваємо критичні модулі тестами. В результаті ваша команда перестає боятися рефакторингу, а CI видає стабільний зелений статус. Наша команда має 7+ років досвіду в автоматизації тестування фронтенд та виконала 50+ проектів з unit-тестів для фронтенду. Ми працюємо з проектами будь-якої складності: від односторінкових додатків до великих корпоративних порталів. Ми не просто пишемо тести — ми проектуємо тестовану архітектуру.

За статистикою наших проектів, впровадження unit-тестів скорочує час регресійного тестування на 40% і зменшує кількість багів у продакшені на 25%. Це пряма економія бюджету на QA та підтримку — в середньому 2-3 місяці роботи QA, що становить економію від 200 000 до 500 000 рублів на рік на команду з 5 розробників. Для команди з 5 розробників річна економія може сягати $15,000, а для команди з 10 розробників — до $30,000. Більше того, добре написані тести служать документацією та спрощують онбординг розробників. Вартість базового пакету починається від 30 000 грн, розширеного — від 60 000 грн.

Однак багато команд стикаються з типовими труднощами: нестабільні тести через невірні моки, відсутність покриття кастомних хуків і складна конфігурація Jest з TypeScript. Розберемося, як вирішити ці проблеми, на прикладі наших проектів.

Проблеми, які вирішує unit-тестування

• Нестабільні тести через невірні mock'и та брудне оточення. Типовий проект з 20-30 компонентами вимагає акуратного управління станом та моками.
• Відсутність покриття для кастомних хуків та ред'юсерів — логіка залишається без захисту. Без тестів кожен рефакторинг — ризик.
• Складна конфігурація Jest+React+TypeScript — плутанина з трансформацією, аліасами та стилями. Ми налаштовуємо все від jest.config.ts до setupFilesAfterFramework, використовуючи сучасний стек: Jest 29, @swc/jest для швидкої трансформації, React Testing Library для компонентів, MSW для моків API.

Налаштування займає 2-4 години, а результат — стабільний CI та відчутна економія бюджету. Unit-тестування краще за ручне регресійне тестування в 5 разів за вартістю.

Як налаштувати Jest для React-проекту з TypeScript?

Стандартна конфігурація включає:

npm install -D jest @types/jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom 

// jest.config.ts export default { testEnvironment: 'jsdom', setupFilesAfterFramework: ['<rootDir>/jest.setup.ts'], moduleNameMapper: { '^@/(.*)$': '<rootDir>/src/$1', '\.(css|scss)$': 'identity-obj-proxy', }, transform: { '^.+\.(ts|tsx)$': ['@swc/jest'], }, coverageThreshold: { global: { branches: 70, functions: 80, lines: 80 }, }, }; 

Ця конфігурація підтримує аліаси, CSS-модулі та TypeScript. coverageThreshold гарантує мінімальний рівень покриття — інакше пайплайн впаде. Докладніше про налаштування можна прочитати в Офіційна документація Jest.

Для проектів на Next.js або Vue знадобляться невеликі зміни: додайте testEnvironment: 'jsdom' та налаштуйте трансформацію під ваш фреймворк. Ми підбираємо конфіг індивідуально.

Як тестувати кастомні хуки та асинхронні запити?

Кастомні хуки містять бізнес-логіку, яка повторюється в різних компонентах. Без тестів ви ризикуєте отримати неочікувану поведінку при зміні стейту. API-запити — вузьке місце: змінюється бекенд, падає таймаут, повертається 404. MSW перехоплює запити на рівні мережі, що швидше та надійніше за ручні mock'и. Використання MSW краще за ручні моки в 3 рази за продуктивністю та надійністю.

Порівняння підходів до мокування API

MSW працює в 2-3 рази швидше за ручні mock'и, а також точніше імітує поведінку сервера.

Що входить у роботу

• Налаштований Jest з конфігом під ваш стек.
• 30–50 unit-тестів на утиліти, хуки, компоненти та сервіси.
• Інтеграція з CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Документація щодо запуску, додавання нових тестів та роботи з моками.
• Гарантія стабільності: тести проходять, coverage не нижче обумовленого порогу (зазвичай 80%).

Приклади тестів

Тестування утиліт

// src/utils/currency.ts export const formatCurrency = (amount: number, locale = 'ru-RU', currency = 'RUB') => new Intl.NumberFormat(locale, { style: 'currency', currency }).format(amount); // src/utils/currency.test.ts describe('formatCurrency', () => { it('formats RUB correctly', () => { expect(formatCurrency(1500)).toMatch('1 500'); }); it('handles zero', () => { expect(formatCurrency(0)).toMatch('0'); }); it('formats USD', () => { expect(formatCurrency(99.99, 'en-US', 'USD')).toBe('$99.99'); }); }); 

Тестування React-компонентів

// components/Button.test.tsx import { render, screen, fireEvent } from '@testing-library/react'; import userEvent from '@testing-library/user-event'; import { Button } from './Button'; describe('Button', () => { it('renders label', () => { render(<Button>Зберегти</Button>); expect(screen.getByRole('button', { name: 'Зберегти' })).toBeInTheDocument(); }); it('calls onClick', async () => { const onClick = jest.fn(); render(<Button onClick={onClick}>Click me</Button>); await userEvent.click(screen.getByRole('button')); expect(onClick).toHaveBeenCalledTimes(1); }); it('disabled button does not fire onClick', async () => { const onClick = jest.fn(); render(<Button onClick={onClick} disabled>Disabled</Button>); await userEvent.click(screen.getByRole('button')); expect(onClick).not.toHaveBeenCalled(); }); it('shows loading spinner when loading', () => { render(<Button loading>Save</Button>); expect(screen.getByRole('button')).toHaveAttribute('aria-busy', 'true'); expect(screen.getByTestId('spinner')).toBeInTheDocument(); }); }); 

Тестування API-запитів

// services/api.test.ts import { rest } from 'msw'; import { setupServer } from 'msw/node'; import { fetchUser } from './api'; const server = setupServer( rest.get('/api/users/:id', (req, res, ctx) => { return res(ctx.json({ id: 1, name: 'Іван' })); }) ); beforeAll(() => server.listen()); afterEach(() => server.resetHandlers()); afterAll(() => server.close()); test('fetchUser returns user data', async () => { const user = await fetchUser(1); expect(user.name).toBe('Іван'); }); test('fetchUser handles 404', async () => { server.use( rest.get('/api/users/:id', (req, res, ctx) => res(ctx.status(404))) ); await expect(fetchUser(999)).rejects.toThrow('Not found'); }); 

Процес роботи

1. Аналіз проекту: структура, основні модулі, критичні шляхи. Займає 2–4 години.
2. Налаштування Jest та тестового оточення. Підключаємо бібліотеки, прописуємо аліаси.
3. Написання тестів (2–4 дні) з пріоритетом на бізнес-логіку. Ми інтегруємо Jest у проект, пишемо тести для React хуків та налаштовуємо CI/CD тестування.
4. Інтеграція в CI — додавання кроку npm test -- --coverage.
5. Передача документації та консультація команди.

Строки виконання

Точні строки називаємо після аудиту вашого проекту. Залиште заявку — ми оцінимо обсяг і запропонуємо варіанти.

Зв'яжіться з нами для консультації — розкажемо, як покращити покриття та прискорити CI. Замовте unit-тести під ключ і отримайте стабільний продакшен.