Менторы по Jest

Jest: проверьте поведение, которое действительно важно

Зелёный тест не всегда означает, что функция работает правильно. Он может проверять собственную заглушку, пропускать асинхронное завершение или зависеть от порядка запуска. Разбор с наставником по Jest полезно начинать с того, какое нарушение тест обязан заметить.

Свяжите проверку с наблюдаемым результатом

Выберите небольшую функцию или пользовательский сценарий. Сформулируйте допустимый вход, ожидаемый результат и существенный случай ошибки. Затем посмотрите, сможет ли тест отличить корректную реализацию от намеренно неверной.

Например, обработчик должен вернуть понятную ошибку, если сервис отклонил запрос. Если проверяется только факт вызова заглушки, поведение обработчика остаётся неизвестным. Попросите наставника показать, какое утверждение связывает тест с результатом для вызывающего кода.

Ограничьте роль моков

Мок позволяет управлять внешней зависимостью и наблюдать обращения к ней. Но он должен соответствовать используемому контракту. Заглушка, которая всегда возвращает удобное значение, может скрыть ошибку формата или обработки отказа.

Отдельно проверьте очистку состояния между тестами. Сохранённая история вызовов, изменённые глобальные значения и управляемые таймеры способны повлиять на соседние проверки. Для асинхронных сценариев важно, чтобы тест действительно дождался обещания или другого события завершения.

Разберите нестабильность отдельно от бизнес-ошибки

Если тест иногда падает в CI, сохраните команду запуска, окружение и сообщение об ошибке. Попробуйте запускать проверку отдельно и вместе с набором. Это помогает искать общие ресурсы, зависимость от времени и утечки состояния.

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