Есть ли автотесты?

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

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

Как отвечать

Отвечайте про свой реальный проект: какие тесты были, на чём, кто их писал и когда они запускались. Каркас такой:

• юнит-тесты: чистые функции, хуки, форматирование, редьюсеры. Инструменты: Vitest или Jest;
• компонентные: React Testing Library, проверка через то, что видит пользователь (getByRole, getByLabelText, события через user-event). Сеть подменяют через MSW, а не моками fetch в каждом тесте;
• e2e: Playwright или Cypress на несколько критичных сценариев: вход, оформление заказа, оплата;
• прочее: визуальная регрессия по скриншотам, проверки доступности, TypeScript как первая линия защиты.

Хорошо звучит, когда вы объясняете выбор. Во фронтенде часто опираются на «тестовый трофей»: основной вес на интеграционных тестах компонентов, а e2e немного, потому что они медленные и хрупкие. И называете, как это работало: тесты гоняются на каждый пул-реквест, красный CI блокирует мерж.

Если тестов не было, так и скажите и объясните почему: прототип, сроки, решение команды. Затем покажите, с чего бы начали: e2e на критичный путь и юнит-тесты на сложную логику. Выдуманный процент снижения багов разваливается на первом же уточнении.

Этот же вопрос полезно задать компании. Ответы «тесты пишут тестировщики отдельно» или «тестов нет, но скоро будут» стоит уточнить до оффера.

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

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

Выдают снапшот-тесты за стратегию. Огромный снапшот обновляют не глядя, и он перестаёт что-либо проверять.

Ставят целью 100% покрытия. Метрика легко набирается бесполезными тестами, а важный сценарий остаётся без проверки.