Что должно запускаться в CI/CD Pipeline быстрее — Unit Test или Integration Test?

В пайплайне Unit-тесты должны запускаться и завершаться значительно быстрее, чем Integration-тесты. Это основа стратегии "fail fast" (быстрое обнаружение ошибок).

Почему это важно:

• Unit-тесты изолированы, не требуют внешних зависимостей (база данных, API-гейтвеи, другие сервисы) и выполняются за секунды. Если они падают, разработчик получает фидбек почти мгновенно, еще до затратных по времени этапов.
• Integration-тесты требуют развертывания тестового окружения (поднятие контейнеров с БД, моки сервисов, настройка сети), что занимает минуты. Их запуск на ранних стадиях пайплайна замедлит получение обратной связи по простым ошибкам.

Пример структуры этапов в GitLab CI:

stages:
  - build
  - test-unit    # Быстрые тесты
  - test-integration # Медленные тесты
  - deploy

# 1. Сборка
build_job:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

# 2. Быстрые Unit-тесты (запускаются первыми)
unit_tests:
  stage: test-unit
  script:
    - docker run --rm $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA npm test  # или pytest, go test

# 3. Медленные Integration-тесты (запускаются после успеха unit-тестов)
integration_tests:
  stage: test-integration
  script:
    - docker-compose -f docker-compose.test.yml up -d  # Поднимаем полное окружение
    - ./run_integration_tests.sh
  needs: ["unit_tests"]  # Зависимость от успешного прохождения unit-тестов

Оптимизация:

• Параллельный запуск suites unit-тестов.
• Кэширование зависимостей (node_modules, pip packages) между запусками пайплайна.
• Для integration-тестов можно использовать предварительно развернутые и готовые тестовые среды, чтобы не тратить время на их создание с нуля каждый раз.