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

Что проверяют

Знаете ли вы современный набор инструментов, а не список из статьи пятилетней давности, и понимаете ли, какой уровень пирамиды каким инструментом закрывается. Тестировщику следом часто задают вопрос, какие проверки вы оставите разработчикам в компонентных тестах, а какие заберёте в e2e.

Как отвечать

Разложите по уровням:

• раннер: Jest или Vitest. Vitest естественен для проектов на Vite и совместим с API Jest (describe, expect, моки через vi.fn() вместо jest.fn()). Обоим нужно DOM-окружение jsdom или happy-dom, у Jest по умолчанию node;
• React Testing Library: рендер компонента и поиск элементов так, как их видит пользователь. Приоритет запросов: getByRole, затем getByLabelText и getByText, и только в крайнем случае getByTestId. Действия лучше делать через @testing-library/user-event, а не fireEvent: он воспроизводит всю цепочку событий;
• @testing-library/jest-dom: матчеры toBeVisible, toBeDisabled, toHaveTextContent;
• MSW: перехват запросов на уровне сети. Компонент ходит в «настоящий» API, а тест подменяет ответ, включая ошибки и задержки;
• Storybook: компоненты в разных состояниях, взаимодействия через play-функции, визуальные снимки и проверка доступности через axe;
• Playwright или Cypress: e2e по пользовательским сценариям, у обоих есть и режим компонентного тестирования.

Отдельно скажите про асинхронность: findBy* ждёт появления элемента, queryBy* нужен для проверки отсутствия, waitFor для остальных ожиданий.

Где спотыкаются

Называют Enzyme рабочим вариантом. Официального адаптера для React 17 и новее у него нет, в новых проектах он не применяется, а react-test-renderer в React 19 объявлен устаревшим.

Проверяют реализацию: state, имена классов, количество вызовов внутреннего хука. Такие тесты ломаются от любого рефакторинга и при этом не ловят реальные дефекты.

Сваливают всё в e2e. Проверка десятка состояний формы через браузер медленная и нестабильная, а на компонентном уровне она занимает миллисекунды.