Есть ли опыт описания тестов
Что проверяют
Пишете ли вы тесты сами и понимаете ли, что и зачем тестировать во фронтенде. Иногда под «описанием тестов» имеют в виду тест-кейсы для QA, поэтому уточните, о чём речь. Следом обычно просят рассказать про конкретный тест или про то, как вы подменяете запросы к API.
Как отвечать
Это вопрос про ваш опыт, поэтому каркас общий, а наполнение только своё:
- уровни: юнит-тесты для утилит и хуков, компонентные тесты, e2e для критичных сценариев. Назовите инструменты, с которыми работали: Vitest или Jest, React Testing Library, Playwright или Cypress, MSW для подмены сети;
- как пишете:
describeпо модулю,itс именем, которое читается как требование, напримерit('показывает ошибку, если email пустой'). Внутри схема «подготовка, действие, проверка». Элементы ищете так, как их видит пользователь:getByRole,getByLabelText, действия черезuserEvent; - что проверяете: поведение, а не внутренности. Не значение
useState, а то, что после клика появился текст или ушёл запрос; - где запускаются: в CI на каждый пулреквест, падение блокирует мерж;
- пример: один конкретный случай, когда тест поймал регрессию до релиза.
Цифры приводите только свои и проверяемые: сколько тестов, как покрыты критичные модули, сколько длится прогон. Если данных нет, лучше без цифр, чем с придуманными процентами.
Если опыта мало, скажите прямо: в рабочем проекте тестов не было или их писали другие, но в своём проекте вы покрыли, например, форму регистрации тестами на RTL и можете показать репозиторий. Честный небольшой пример весит больше, чем пересказ документации.
Где спотыкаются
Тестируют детали реализации: имена классов, внутренний стейт, число вызовов setState. Такие тесты ломаются от любого рефакторинга и ничего не гарантируют.
Строят проверки на снапшотах целых страниц. Снапшот на сотни строк никто не читает, при падении его просто обновляют.
Называют тесты it('работает') или test1. Интервьюер может попросить показать код, и названия сразу выдают, описывали вы поведение или добавляли тесты ради покрытия.