Как обстоят дела с юнит тестами

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

Пишете ли вы тесты по-настоящему и понимаете ли, что именно стоит покрывать во фронтенде. Вопрос открытый, поэтому следом почти всегда идёт «покажите тест, который поймал баг» или «какое у вас покрытие и как вы к нему относитесь».

Как отвечать

Отвечайте про свой проект и со своими цифрами: сколько тестов, сколько длится прогон, блокирует ли красный CI слияние. Опорный каркас:

• инструменты: Vitest или Jest, React Testing Library с @testing-library/user-event, окружение jsdom или happy-dom, MSW для подмены сети. Для хуков renderHook из той же библиотеки;
• что покрываете юнитами: чистые функции, форматтеры, валидацию форм, редьюсеры и сторы, хуки с логикой. Компонент проверяете через то, что видит пользователь: getByRole, клик, текст на экране, а не внутренний state;
• где граница: сценарии через несколько страниц уходят в e2e на Playwright или Cypress, внешний вид в скриншотные тесты. Юнит не должен знать про роутер и реальный бэкенд;
• процесс: тесты гоняются в CI на каждый PR, тест на баг пишется вместе с фиксом, покрытие служит подсказкой, а не планом.

Если тестов в проекте почти не было, не приукрашивайте. Скажите, почему (прототип, сроки, легаси без изоляции), и что сделали сами: покрыли утилиты, подняли Vitest, добавили тест на регрессию. Это честнее и сильнее, чем «конечно, всё покрыто».

Вопрос работает и в обратную сторону: задайте его работодателю. Ответы «тестов нет, но хотим» или «тесты есть, но CI их не запускает» многое скажут о кодовой базе, в которую вы идёте.

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

Называют целью 100% покрытия. Такое покрытие добирают тестами без проверок, и интервьюер это знает.

Тестируют детали реализации: имена классов, вызовы setState, огромные снапшоты. Любой рефакторинг ломает десятки тестов без единого бага.

Говорят общие слова про пользу тестов и не приводят ни одного конкретного примера из своей практики.