Есть ли требования к тестируемости кода, например минимальное покрытие тестами?

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

Понимаете ли вы, что покрытие это инструмент, а не цель, и можете ли рассказать, как требования к тестам устроены на вашем проекте. Следом обычно спрашивают, какое покрытие вы считаете разумным и что делать, если новый код его роняет.

Как отвечать

Расскажите, как было у вас, затем покажите механику:

• метрики: statements, branches, functions, lines. Самая честная из них branches: строки легко покрыть, не проверив ни одной ветки if;
• инструменты: Jest или Vitest собирают покрытие через Istanbul или встроенное в V8 (@vitest/coverage-v8). Порог задаётся в конфиге, coverageThreshold в Jest и coverage.thresholds в Vitest, и при недоборе прогон падает;
• где проверяется: в CI отдельным шагом или через quality gate в SonarQube и Codecov. Удобнее требовать покрытия нового кода, а не всего проекта: старый код не блокирует работу, а свежий не уходит без тестов;
• тестируемость: логика вынесена из компонентов в хуки и чистые функции, сеть подменяется через MSW, компоненты проверяются через Testing Library по ролям и текстам, как их видит пользователь, а не по внутреннему состоянию;
• уровни: юнит на утилиты и сложную логику, интеграционные тесты на компоненты и формы, несколько e2e на Playwright или Cypress для ключевых сценариев.

Про цифру: единого стандарта нет. 80% часто берут как договорённость, но важнее, что именно покрыто. Сгенерированный код, конфиги и тонкие обёртки над UI-библиотекой разумно исключить из отчёта через coveragePathIgnorePatterns или coverage.exclude.

Если на проекте требований не было, скажите прямо и объясните, что ввели бы сами: порог на новый код и обязательный тест на каждый исправленный баг.

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

Называют 80% «общепринятым стандартом» и не могут объяснить, откуда число. Интервьюеру интереснее, как вы решаете, что покрывать.

Пишут тесты ради процента: рендер без единой проверки даёт покрытие, но не ловит ни одной ошибки. Качество тестов показывает мутационное тестирование, например Stryker.

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