Использовал ли Jest

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

Писали ли вы тесты дальше проверки чистых функций и понимаете ли, что и как стоит тестировать в интерфейсе.

Как отвечать

Расскажите, что именно покрывали и как:

• чистая логика: форматирование, расчёты, редьюсеры, работа с датами. Самые дешёвые и полезные тесты;
• компоненты: через Testing Library, проверяя поведение глазами пользователя (видит текст, нажимает кнопку, получает результат), а не внутреннее состояние;
• запросы: перехват на уровне сети через MSW вместо подмены функции fetch. Так тест проверяет реальную цепочку и не ломается при смене клиента;
• снимки (snapshot): применимы точечно, потому что большой снимок никто не читает и его обновляют не глядя.

Что показывает опыт: разница между getBy, queryBy и findBy; работа с асинхронностью через waitFor вместо пауз; подмена таймеров через useFakeTimers; изоляция тестов и очистка состояния между ними; настройка окружения (jsdom), трансформация TypeScript, покрытие как ориентир, а не цель.

Полезно добавить актуальный контекст: во многих новых проектах вместо Jest берут Vitest, потому что он работает с той же экосистемой, но быстрее стартует и лучше дружит со сборкой на Vite. Если сталкивались с обоими, скажите, чем отличались.

Если опыта мало, честно назовите уровень и то, что писали сами, а не пересказывайте документацию.

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

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

Заменяют ожидание паузами и получают нестабильные прогоны.

Гонятся за процентом покрытия, покрывая тривиальный код и оставляя без проверок сложные ветвления.