Что такое Unit-тестирование

Unit-тестирование проверяет небольшую единицу поведения отдельно от остальной системы. В ответе не нужно спорить о том, что именно считать unit во всех проектах. Лучше сказать практично: это может быть функция, модуль, хук, редьюсер или компонент, если вы контролируете его зависимости и проверяете конкретное поведение.

Удобная устная формулировка: unit-тест отвечает на вопрос, получу ли я ожидаемый результат, если дам этой части кода известные входные данные и контролируемые зависимости.

Во frontend unit не всегда равен одной функции. Простая функция форматирования цены подходит идеально. Хук можно тестировать как единицу логики состояния. Компонент можно тестировать как unit, если вы изолируете внешние зависимости и проверяете его наблюдаемое поведение: что показано пользователю, какие элементы доступны с клавиатуры, какие labels связаны с полями и что происходит после действия.

Не стоит говорить, что unit-тесты это только тесты на чистые функции. Для учебного примера такая фраза подходит, но для React и Next.js практики она слишком узкая. В реальном интерфейсе ошибки часто появляются в ветвлениях, состояниях загрузки, обработке ошибок и повторных действиях пользователя.

Хороший unit-тест обычно держится на трех вещах.

• Изоляция. Тест не ходит в реальную сеть, не зависит от текущего времени, порядка запуска и состояния браузера.
• Повторяемость. Один и тот же код с теми же входными данными дает тот же результат.
• Проверка поведения. Тест проверяет результат, видимый эффект или контракт функции, а не внутреннюю раскладку переменных.

Если вас спрашивают про инструменты, можно назвать Jest, Vitest, React Testing Library или похожий стек. Но не превращайте ответ в список библиотек. На интервью обычно проверяют не названия фреймворков, а понимание того, что именно и зачем вы проверяете.

Самая частая слабость ответа: unit-тест проверяет одну функцию. Это не совсем ошибка, но формулировка слишком узкая. Во frontend важна граница поведения. Например, компонент может показывать spinner, потом список, потом ошибку после неуспешного запроса. Unit-тест такого компонента не обязан обращаться к реальному API. Он должен контролировать ответ зависимости и проверять, что UI корректно переходит между состояниями.

Еще одна ловушка состоит в том, чтобы мокать все подряд. Если вы замокали и внешний API, и саму функцию расчета, тест больше не проверяет полезную логику. Моки нужны на границах: сеть, время, навигация, хранилище, browser-only API. Проверяемую часть лучше оставлять настоящей. Иначе можно получить зеленый тест, который скрывает реальный баг. Например, расчет цены не запускается после ошибки запроса, кнопка остается disabled или старый ответ перезаписывает новый список.

На интервью полезно объяснить, где unit-тесты дают максимальную ценность.

• Форматирование, валидация, расчет, сортировка и фильтрация.
• Редьюсеры и функции обновления состояния.
• Хуки с ветвлениями, кешированием или асинхронными переходами.
• Компоненты, где важны disabled state, ошибка, пустой список, фокус, labels, доступная разметка и реакции на действия.
• Регрессии, которые уже ломались и должны быть зафиксированы тестом.

Не обещайте покрыть unit-тестами каждую строку. Более зрелый ответ звучит так: я начинаю с критичной логики и рискованных веток, а для связки нескольких частей добавляю интеграционные тесты.

Для frontend особенно важно упомянуть асинхронность. Если код получает данные, unit-тест может проверять не только успешный ответ. Часто нужно проверить loading, error, empty state, повторную отправку и защиту от устаревшего результата. Например, если пользователь быстро меняет фильтр, старый ответ не должен перезаписать новый список.

При этом реальный запрос в unit-тесте обычно не нужен. Его заменяют контролируемой зависимостью. Так тест отвечает за логику компонента, а не за доступность внешнего API или стабильность сети. Если у сценария есть retry или rollback после ошибки, это тоже лучше проверить явно. Иначе пользователь может остаться с устаревшими данными или заблокированной кнопкой.

Unit-тест не доказывает, что вся страница работает в браузере так, как ожидает пользователь. Он может не поймать ошибку маршрутизации, несовпадение SSR и CSR, проблему фокуса, реальную сетевую политику, XSS из небезопасного рендера внешних данных, производительность тяжелой страницы или некорректную интеграцию с backend.

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