Coverage

Тема дорожной карты · Node.js

Покрытие кода измеряет долю строк, ветвей, функций и выражений исходного кода, задействованных набором тестов, предоставляя командам серверной разработки Node.js объективный показатель полноты тестирования. Наиболее распространённый инструмент для создания отчётов о покрытии в проектах Node.js — jest --coverage, который инструментирует JavaScript-исходники с помощью Istanbul (теперь nyc) и выводит HTML- или LCOV-отчёт, показывающий, какие части серверного кода ни разу не выполнялись в ходе тестирования. Пороги покрытия можно задать в jest.config.js или package.json через параметр coverageThreshold, заставляя CI-конвейер завершаться с ошибкой, если покрытие падает ниже заданного процента по строкам, ветвям или функциям. В Node.js 22 появился встроенный тест-раннер с нативной поддержкой покрытия через node --experimental-test-coverage, что снижает потребность в сторонних инструментах в ряде сценариев. Достижение высокого покрытия кода в серверных сервисах Node.js — особенно для путей обработки ошибок и асинхронных крайних случаев — повышает надёжность продакшна и снижает риск регрессий при рефакторинге.

Как это работает

Coverage имеет несколько test-runner: встроенный node:test (Node 20+, без установки), Vitest (быстрый, Vite-native, Jest-совместимый), Jest (зрелый, большая экосистема), Mocha (классический, гибкий). Ассерты: node:assert, chai, expect. Моки: встроенный mock в node:test, sinon, vitest mock. Integration-тесты обычно поднимают приложение + test DB; HTTP-ассерты через supertest. Coverage — через c8 или nyc.

Когда применять

Vitest — для новых проектов: быстрый, ESM-native, watch-mode перезагружает только изменившееся. node:test — для zero-dependency ситуаций (CI-раннеры, внутренности npm-пакетов). Jest — только в legacy. Тесты в CI на каждый PR. Реальная test DB для integration-тестов (testcontainers поднимает на запуск); мокайте только реально внешнее (third-party API, payment-шлюзы).

Типичные ошибки

Ловушки Coverage: тесты, делящие state (строка БД из теста A роняет тест B); over-mocking (тестируете моки, не код); process.exit() в тестах (убивает runner); нет timeout (висящий promise вешает suite); snapshot-тесты на нестабильном выводе (каждое изменение — diff). Тестовый suite — это production-код; рефакторьте его, именуйте хорошо.

Связанные понятия

Полезные ресурсы