Тесты приносят пользу только тогда, когда исполняются автоматически на каждое изменение. Набор, который гоняют вручную и по настроению, не защищает ничего: регрессию замечают уже в проде. Задача CI - сделать проверку неотвратимой: на каждый push и pull request машина прогоняет один и тот же конвейер, и красный результат блокирует слияние. Локальный зелёный - это гипотеза; зелёный в CI - подтверждение на чистой, воспроизводимой машине.

Конвейер выстраивают в понятном порядке, от дешёвого к дорогому. Сначала npm ci - установка строго по lockfile, без своевольного обновления версий. Затем быстрые проверки: lint и typecheck отдельным шагом, потому что тесты не заменяют tsc --noEmit. Дальше сами тесты в CI-режиме, и только в конце build. Такой порядок даёт быстрый отказ: очевидная ошибка линтера валит сборку за секунды, не дожидаясь долгих шагов.

Тесты в CI запускают явным одноразовым прогоном, а не watch. vitest run выполняет набор один раз и выходит с кодом, по которому CI судит об успехе; забытый watch-режим повесил бы job навсегда. Обычно это связывают в скрипт вроде test:ci, добавляя vitest run --coverage, чтобы за один проход получить и результат, и покрытие, и не гонять набор дважды ради отчёта.

Когда набор разрастается, помогает шардирование. Флаг --shard=1/3 разбивает тесты на части, и три параллельные job'ы прогоняют треть каждая, сокращая общее время примерно втрое. Это горизонтальное масштабирование прогона: набор тот же, но исполняется параллельно на нескольких раннерах. Coverage при этом собирают по шардам и сливают в общий отчёт, чтобы дробление не потеряло часть данных.

Воспроизводимость CI держится на фиксации окружения. Версию Node закрепляют явно - той же, что у команды и в проде, - а установка идёт по закоммиченному lockfile, поэтому машина видит ровно те же версии зависимостей. Кэш стора пакетного менеджера ускоряет установку между прогонами, не меняя её результата. Без этой дисциплины 'у меня работает' и 'в CI падает' становятся нормой, а причина - плавающие версии, а не код.

Результаты прогона стоит сохранять как артефакты. Отчёт покрытия и результаты в формате JUnit подключают к job'е, чтобы CI показывал их в интерфейсе: какие тесты упали, как менялось покрытие, где регрессия. Это превращает прогон из бинарного 'прошло/не прошло' в диагностику - по артефактам видно, что именно сломалось, без локального воспроизведения всего пайплайна с нуля.