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

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

За статистикою наших проектів, впровадження unit-тестів скорочує час регресійного тестування на 40% і зменшує кількість багів у продакшені на 25%. Це пряма економія бюджету на QA та підтримку — в середньому 2-3 місяці роботи QA, що становить економію від $2k–5kів на рік на команду з 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 = 'USD') =>
  new Intl.NumberFormat(locale, { style: 'currency', currency }).format(amount);

// src/utils/currency.test.ts
describe('formatCurrency', () => {
  it('formats USD 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-тести під ключ і отримайте стабільний продакшен.