Unit тестирование с Jest — понятие, которое вызывает у многих разработчиков одновременно интерес и раздражение. Этот инструмент действительно умеет многое: быстрый запуск, мощные заглушки, понятные отчёты и удобные снапшоты. В статье постараюсь пройти шаг за шагом от установки до практических приёмов, которые помогут писать надёжные тесты без лишнего бюрократизма.
Зачем нужны модульные тесты и почему Jest
Модульные тесты проверяют отдельные единицы кода — функции, классы, маленькие сервисы. Они дают уверенность при рефакторинге, помогают ловить регрессии и документируют ожидаемое поведение кода в явном виде.
Jest при этом удобен тем, что почти всё нужно «из коробки»: раннер, assertion-библиотека, мок-функции и синхронизация асинхронного кода. Это уменьшает время настройки проекта и позволяет сосредоточиться на самих тестах, а не на инфраструктуре.
Быстрый старт: установка и базовая конфигурация
Установить Jest просто: достаточно npm или yarn. В типичном проекте на Node или React достаточно выполнить одну команду и добавить короткий скрипт в package.json для запуска тестов.
Конфигурировать Jest можно через поле jest в package.json или отдельный файл jest.config.js. Часто достаточно дефолтных настроек, но если проект использует TypeScript, трансформеры и alias-пути, потребуется настроить transform и moduleNameMapper.
Пример базовой установки
Для простого проекта на JavaScript достаточно:
npm install --save-dev jest
# package.json
"scripts": {
"test": "jest"
}Если используется TypeScript, добавьте ts-jest и настройте transform. Это типичный сценарий: один шаг установки и тесты уже запускаются.
Структура теста: describe, it, expect
Тесты в Jest обычно организуют с помощью describe для группировки и it (или test) для отдельных проверок. Это даёт читабельную структуру в отчётах и помогает поддерживать порядок в больших наборах тестов.
Ключевая часть каждой проверки — expect. С его помощью формулируется утверждение о результате: что функция вернёт, как обработает исключение или как изменится состояние объекта.
Простейший пример
Представим функцию add(a, b). Тест для неё может выглядеть так:
describe('add', () => {
it('складывает два числа', () => {
expect(add(2, 3)).toBe(5);
});
});Такой тест короткий, понятный и сразу показывает контракт функции. На практике полезно проверять как типичные случаи, так и граничные ситуации.
Matchers: чего можно ожидать
Jest предоставляет набор матчеров для сравнения значений: toBe, toEqual, toContain, toHaveLength и другие. Выбор матчера зависит от типа сравнения — строгое равенство или глубокое сравнение объектов.
Ниже небольшая таблица с часто используемыми матчерами и их назначением.
| Матчер | Применение |
|---|---|
| toBe | Строгое равенство примитивов |
| toEqual | Глубокое сравнение объектов и массивов |
| toContain | Проверка наличия элемента в массиве или подстроки в строке |
| toThrow | Ожидание исключения |
Моки, стабы и spy-функции
При тестировании часто нужно изолировать код от внешних зависимостей: сетевых запросов, файловой системы, времени. Jest предлагает удобные механизмы для этого: jest.fn(), jest.mock() и шпионские функции.
Моки позволяют управлять поведением зависимостей и проверять, как именно вызывается функция. Это особенно важно в сервисах с побочными эффектами, где результат зависит не только от входных параметров.
Пример мокирования модуля
Если модуль fetch вызывает внешнюю API и его нужно заменить в тестах, можно создать мок:
jest.mock('./api', () => ({
getData: jest.fn().mockResolvedValue({ id: 1 })
}));Так тест становится предсказуемым и не зависит от сети. В моих проектах это спасало от флейков, когда внешний сервис падал в CI.
Асинхронный код и таймеры
Асинхронность — частая головная боль. В Jest есть простые способы тестировать промисы, async/await и таймеры. Для промисов используйте return или async/await, а для таймеров — фейковые таймеры.
Фейковые таймеры полезны, когда код откладывает действие через setTimeout или setInterval. Управляя временем вручную, тесты становятся быстрыми и детерминированными.
Пример теста с async/await
it('загружает данные', async () => {
const data = await fetchData();
expect(data).toHaveProperty('id');
});Такой подход читается как обычный последовательный код и снижает шанс пропустить ожидание завершения асинхронной операции.
Снапшот-тестирование: когда это уместно
Снапшоты полезны для UI-компонентов и сложных структур, где нужно зафиксировать выходной формат. Jest умеет сохранять снапшоты в отдельные файлы и сравнивать их при следующих запусках.
Важно использовать снапшоты осознанно: они облегчают обнаружение изменений, но не заменяют проверки логики. Я обычно комбинирую снапшоты с точечными тестами на ключевое поведение.
Организация тестов и лучшие практики
Хорошая организация экономит время при масштабировании проекта. Держите тесты рядом с кодом, но разделяйте по смыслу: unit тесты не должны обращаться к БД или внешним сервисам.
Ниже несколько практических правил, которые зарекомендовали себя в работе.
- Пишите понятные имена тестов, описывающие ожидаемое поведение.
- Тестируйте контракты, а не реализацию — это уменьшит число ложно-положительных изменений при рефакторинге.
- Избегайте больших тестовых фикстур — лучше собирать минимально необходимое состояние.
- Используйте моки для внешних зависимостей и реальные объекты для бизнес-логики.
Code coverage и интеграция в CI
Покрытие кода — полезный индикатор, но не цель. Jest умеет собирать отчёты покрытия и экспортировать их в форматы, удобные для CI-пайплайнов. Главное — смотреть на качество тестов, а не на число процентов.
В CI стоит запускать тесты в отдельном шаге, при этом включать флаги —runInBand или —maxWorkers при необходимости. Я видел проекты, где параллельный запуск в CI приводил к флейкам из-за некорректных моков.
Практические приёмы из моего опыта
Однажды в крупном проекте у нас были частые фейлы из-за времени и случайных данных. Мы ввели явные seed-данные в тестах и использовали фейковые таймеры — число ложных провалов резко упало. Простые меры дали очевидный эффект.
Другой приём: регулярно пересматривать старые тесты при рефакторинге. Иногда тесты начинают проверять детали реализации и мешают улучшениям. При небольшом рефакторинге стоит переработать такие проверки, чтобы они снова проверяли поведение, а не структуру.
Ресурсы и куда двигаться дальше
Документация Jest — лучший старт, но полезны и статьи о проектировании тестов, TDD-практики и обсуждения на профильных площадках. Экспериментируйте: составьте набор тестов для небольшой функции и постепенно увеличивайте сложность.
Если хотите углубиться, посмотрите на интеграцию с TypeScript, тестирование React-компонентов с @testing-library/react и использование Jest вместе с ESLint и Prettier для единообразия кода.
Unit тестирование с Jest — это не волшебная таблетка, но мощный инструмент в арсенале разработчика. Пиши тесты целенаправленно, держи их простыми и поддерживаемыми, и они вернутся вам в виде меньше стрессов при релизах и более уверенного кода.
