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

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

Для тестирования React-компонентов используются: Jest как runner и assertion-библиотека, React Testing Library для рендера и взаимодействия, Cypress или Playwright для E2E-тестов, Storybook с Chromatic для визуального регрессионного тестирования, MSW для мокирования API. Для unit-тестов логики - Vitest или Jest. Выбор зависит от типа тестов: unit, integration или E2E.

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

Основные инструменты делятся на категории:

• Unit-тесты: Jest (наиболее популярен) или Vitest (быстрее, совместим с Vite). Тестируют изолированные функции, хуки, утилиты.
• Component-тесты: React Testing Library (RTL) - рекомендована React-командой, фокусируется на поведении, а не на реализации. Enzyme (устарел, не рекомендуется для новых проектов).
• Integration-тесты: RTL + Jest/Vitest. Проверяют взаимодействие компонентов, роутинг, стейт-менеджмент.
• E2E-тесты: Cypress (удобен для разработки, отладка в реальном браузере), Playwright (быстрее, кросс-браузерный, поддерживает mobile).
• Snapshot-тесты: Jest (встроенный snapshot-механизм), но часто заменяются визуальным регрессионным тестированием.
• Визуальное регрессионное тестирование: Storybook + Chromatic или Percy. Сравнивают скриншоты компонентов.
• Мокирование API: MSW (Mock Service Worker) - перехватывает запросы на уровне service worker, работает и в тестах, и в Storybook.
• Покрытие кода: Istanbul (встроен в Jest), c8 (для Vitest).

Для тестирования асинхронных операций и таймеров используются waitFor, findBy* из RTL, jest.useFakeTimers().

На практике

В реальных проектах стек обычно выглядит так:

• Jest + React Testing Library - для unit и integration тестов.
• Cypress - для E2E (часто с cypress-component-testing для компонентных тестов).
• Storybook + Chromatic - для визуального регрессионного тестирования и документации.
• MSW - для мокирования API во всех типах тестов.

Настройка: Jest конфигурируется через jest.config.js (или vitest.config.ts), RTL добавляется как @testing-library/react. Для асинхронных тестов используют @testing-library/user-event для симуляции пользовательских действий.

Пример типичного теста: рендер компонента, поиск элемента по роли или тексту, симуляция клика, проверка изменения состояния.

Пример кода

JAVASCRIPT
// Тест компонента Button с использованием Jest + RTL
import { render, screen, fireEvent } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import Button from './Button';

test('вызывает onClick при клике', async () => {
  const handleClick = jest.fn();
  render(<Button onClick={handleClick}>Нажми меня</Button>);

  // Поиск по роли и тексту
  const button = screen.getByRole('button', { name: /нажми меня/i });
  
  // Симуляция клика через userEvent (реалистичнее)
  await userEvent.click(button);

  expect(handleClick).toHaveBeenCalledTimes(1);
});

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

Начни с перечисления основных инструментов, затем уточни их назначение. Подчеркни, что выбор зависит от типа тестирования (unit vs integration vs E2E). Упомяни, что React Testing Library - стандарт индустрии, а Enzyme устарел. Добавь про MSW как современный подход к мокированию. Если спросят про визуальное тестирование - расскажи про Storybook + Chromatic. Избегай излишней детализации по каждому инструменту, но покажи понимание trade-off (например, RTL vs Cypress для компонентных тестов).

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

• Понимание пирамиды тестирования и места каждого инструмента.
• Знание современных практик (RTL вместо Enzyme, MSW вместо fetch mocks).
• Умение выбирать инструмент под задачу (не использовать E2E для unit-тестов).
• Опыт с асинхронными тестами и мокированием.
• Осведомленность о визуальном регрессионном тестировании.

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

• Называть только Jest и забывать про RTL или E2E-инструменты.
• Путать snapshot-тесты с визуальным регрессионным тестированием.
• Предлагать Enzyme для новых проектов (устарел, не поддерживается).
• Игнорировать MSW и предлагать моки через jest.mock для API.
• Не упоминать асинхронные утилиты (waitFor, findBy*).
• Думать, что E2E-тесты заменяют unit-тесты (разные цели).