Был ли опыт тестирования собственных компонентов

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

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

Как отвечать

Опирайтесь на свой проект и называйте стек. Для React типичный набор такой:

• раннер: Vitest или Jest с окружением jsdom. В проектах на Vite чаще Vitest, он переиспользует конфиг сборки;
• React Testing Library: рендер компонента и поиск элементов так, как их видит пользователь: getByRole('button', { name: 'Сохранить' }), getByLabelText, для асинхронного появления findBy*;
• @testing-library/user-event: клики и ввод текста, близкие к настоящим, вместо низкоуровневого fireEvent;
• MSW: перехватывает запросы на сетевом уровне, компонент работает со своим настоящим fetch, а тест проверяет загрузку, ошибку и пустой ответ;
• Storybook: истории как документация и основа для interaction и визуальных тестов;
• Playwright: сквозные сценарии, где важны реальный браузер и роутинг.

Для Vue аналогом будут Vue Test Utils и Vue Testing Library, для Angular TestBed.

Хороший ответ звучит примерно так: «Покрывал форму оформления заказа: валидацию полей, блокировку кнопки во время отправки, текст ошибки при 500 от сервера. Тест на двойной клик поймал повторную отправку заказа». Детали берите свои, а цифры покрытия называйте реальные или не называйте вовсе.

Если своих тестов не писали, признайте это, расскажите, как проверяли компоненты вручную и с чего начали бы: с форм и компонентов с логикой, а не с кнопок.

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

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

Делают снапшоты всего дерева. Их обновляют не глядя, и через месяц они ничего не проверяют.

Мокают всё подряд, включая дочерние компоненты и хуки, и тест доказывает только то, что моки вызваны. Сюда же относится привычка игнорировать предупреждения про act(...) и лечить асинхронность через setTimeout в тесте.