Зачем нужны unit тесты

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

Понимаете ли вы, какую конкретную пользу юнит-тесты дают фронтенду и где их граница. Общих слов про «качество кода» мало. Следом обычно спрашивают, что именно вы тестируете в компонентах и чем юнит-тест отличается от интеграционного и e2e.

Как отвечать

Юнит-тест проверяет небольшой кусок кода изолированно и работает за миллисекунды. Польза для фронтенда:

• быстрая обратная связь: vitest или jest --watch показывает поломку через секунды после сохранения, без сборки и ручного прокликивания;
• безопасный рефакторинг: переписать хук или вынести логику из компонента можно без страха, если тесты описывают поведение, а не устройство;
• граничные случаи: пустой список, null из API, часовые пояса в форматировании дат, округление цен. Найденный баг закрывают тестом, чтобы он не вернулся;
• документация: тест показывает, как функцию или компонент предполагается использовать.

Затем назовите, что тестировать. Лучше всего окупаются чистые функции (форматтеры, валидаторы, редьюсеры, селекторы) и хуки через renderHook. Компоненты проверяют через React Testing Library: элементы ищут по роли и тексту (getByRole), действуют через user-event, сеть подменяют через MSW, а не мокают fetch вручную. Окружение jsdom или happy-dom, у Vitest есть и режим запуска в настоящем браузере.

И обозначьте границу: юнит-тесты не ловят вёрстку, CSS, работу с реальным бэкендом и роутингом. Для этого нужны e2e на Playwright и визуальные проверки. Баланс хорошо описывает «тестовый трофей» Кента Доддса: в основании статический анализ, больше всего интеграционных тестов компонентов, юнитов и e2e меньше.

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

Тестируют детали реализации: внутренний state, имена CSS-классов, число вызовов setState. Такие тесты падают на каждом рефакторинге и ничего не защищают.

Гонятся за 100% покрытия. Метрика растёт, а снапшоты на весь экран никто не читает и обновляют не глядя через -u.

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