> Какие инструменты используются для тестирования React-компонентов (React)

Короткий ответ

Основные инструменты: Jest как test runner и библиотека для assertions, React Testing Library для рендера и взаимодействия с компонентами, Vitest как альтернатива Jest в Vite-проектах. Для end-to-end тестов - Playwright или Cypress. Для snapshot-тестов - Jest с react-test-renderer. Storybook с addon-тестами для визуального регрессионного тестирования. Дополнительно: MSW для мокирования API, user-event для симуляции пользовательских действий.

Подробное объяснение

Тестирование React-компонентов делится на несколько уровней. На уровне unit-тестов основной стек - Jest (или Vitest) в паре с React Testing Library (RTL). RTL фокусируется на тестировании поведения компонента с точки зрения пользователя: поиск элементов по aria-ролям, тексту, testid. Это соответствует принципу "test the behavior, not the implementation".

Для интеграционных тестов, где проверяется взаимодействие нескольких компонентов с реальным состоянием и API, добавляют MSW (Mock Service Worker) - он перехватывает HTTP-запросы на уровне service worker, что даёт более реалистичное тестирование, чем ручное мокирование fetch/axios.

Snapshot-тесты (через Jest + react-test-renderer) полезны для быстрого обнаружения неожиданных изменений в разметке, но их легко сломать при рефакторинге.

Для end-to-end тестов стандарт - Playwright (современнее Cypress, быстрее, поддерживает несколько браузеров). Он запускает реальный браузер и проверяет полный пользовательский сценарий.

Storybook с addon-interactions и test-runner позволяет тестировать компоненты в изоляции, проверяя их состояния (loading, error, empty) без запуска всего приложения.

На практике

Выбор инструментов зависит от проекта. Для нового проекта на Vite - Vitest вместо Jest (нативная интеграция, быстрее). Для легаси на CRA - Jest. RTL обязателен, user-event предпочтительнее fireEvent, так как точнее имитирует реальные события.

MSW настраивается один раз и переиспользуется между тестами и Storybook. Для компонентов с внешними данными (графики, таблицы) обязательно писать тесты с разными состояниями: loading, error, empty, success.

CI-пайплайн включает: unit-тесты (Jest/Vitest), lint, type-check, E2E (Playwright) на критический путь. Snapshot-тесты - только для стабильных компонентов, иначе будут ложные срабатывания.

Пример кода

TYPESCRIPT
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { http, HttpResponse } from 'msw';
import { setupServer } from 'msw/node';
import UserProfile from './UserProfile';

const server = setupServer(
  http.get('/api/user/1', () => {
    return HttpResponse.json({ name: 'Alice', email: 'alice@example.com' });
  })
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('displays user name after loading', async () => {
  render(<UserProfile userId={1} />);
  
  expect(screen.getByText(/loading/i)).toBeInTheDocument();
  
  const userName = await screen.findByText('Alice');
  expect(userName).toBeInTheDocument();
  expect(screen.getByText('alice@example.com')).toBeInTheDocument();
});

test('shows error on network failure', async () => {
  server.use(
    http.get('/api/user/1', () => {
      return HttpResponse.error();
    })
  );
  
  render(<UserProfile userId={1} />);
  
  const errorMessage = await screen.findByText(/failed to load/i);
  expect(errorMessage).toBeInTheDocument();
});

Как отвечать на собеседовании

Начни с основного стека: Jest + React Testing Library. Объясни, почему RTL предпочтительнее Enzyme (тестирование поведения, а не реализации). Упомяни user-event для корректной симуляции. Добавь про MSW для API-мокирования - это показывает понимание интеграционных тестов. Для senior-уровня важно рассказать про trade-off: когда использовать E2E (Playwright), когда snapshot, а когда unit. Подчеркни, что тесты должны быть надёжными (не ломаться от рефакторинга) и быстрыми. Если спросят про покрытие - скажи, что 100% покрытие не цель, важнее тестировать критические пути и граничные случаи.

Что проверяет интервьюер

Проверяется знание современного стека тестирования React, понимание разницы между unit, integration и E2E тестами. Важно, что кандидат не просто перечисляет инструменты, а объясняет, когда какой применять и почему. Проверяется понимание принципа "test behavior, not implementation" - это ключевое для RTL. Также оценивается знание проблем: flaky тесты, ложные срабатывания snapshot, сложность поддержки тестов при рефакторинге.

Типичные ошибки

• Предлагать Enzyme вместо RTL (устаревший подход, тестирует внутренности компонента)
• Использовать fireEvent вместо user-event (не учитывает реальное поведение браузера)
• Мокировать дочерние компоненты в unit-тестах (нарушает принцип тестирования поведения)
• Писать snapshot-тесты для динамических компонентов (частые ложные срабатывания)
• Игнорировать тестирование состояний loading/error/empty
• Ставить 100% покрытие как обязательное требование (ведёт к бесполезным тестам)