Автоматизація Unit-тестів у CI/CD: налаштування під ключ

Автоматизація Unit-тестів у CI/CD: налаштування під ключ

Unit-тести є, але запускаються «коли не забудеш перед пушем» — в результаті регресії в продакшн виникають регулярно. Кожен такий інцидент забирає від 2 до 8 годин на відкат та виправлення, не рахуючи впливу на користувачів. Наші інженери налаштовують CI/CD так, щоб кожен коміт перевірявся автоматично: тести запускаються на кожен PR та пуш у захищену гілку. Результат — стабільний master, прискорений code review і жодних сюрпризів при деплої. Ми використовуємо перевірені практики: матрицю версій, паралелізацію, звіти про покриття та блокування мержу при падінні. Оцінимо ваш проект за один день і налаштуємо pipeline під ключ.

Чому варто автоматизувати запуск Unit-тестів у CI/CD?

Без автоматизації кожен розробник витрачає до 10 хвилин на ручний прогін перед кожним комітом. Для команди з 5 осіб це 50 хвилин на день — майже цілий день на місяць лише на запуск тестів. При цьому пропущений впавший тест тягне за собою дефект у продакшні, вартість виправлення якого в 10 разів вища, ніж якби він був виявлений у CI. Автоматизація знімає ці ризики: pipeline гарантує запуск, паралелізація прискорює прогін у 3–4 рази, а звіти дають прозорість.

Проблеми, які вирішуємо

Ручний запуск тестів — джерело крихкості: розробник може забути прогнати тести перед пушем або пропустити впавший тест у лозі. У результаті помилка йде в продакшн, а відкат коштує дорожче налаштування CI. Інша біль — довгий прогін: 500 тестів без паралелізації виконуються 5–10 хвилин, що гальмує цикл розробки. Нарешті, без формальних звітів важко зрозуміти, які тести впали і чому. Ми вирішуємо всі три проблеми: автоматизація гарантує запуск, паралелізація економить час, а інтеграція Test Summary дає прозорість.

Як ми налаштовуємо CI/CD для Unit-тестів

GitHub Actions з Jest (JavaScript/TypeScript)

Базовий pipeline запускає тести на кожен PR та пуш у main/develop. Використовуємо actions/setup-node@v4 з кешуванням — це економить 1–2 хвилини на встановленні залежностей.

---
# .github/workflows/test.yml
name: Unit Tests
on:
  push:
    branches: [main, develop]
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: Run unit tests
        run: npm test -- --ci --runInBand --coverage
      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/
          retention-days: 7

Прапори для Jest у CI:

• --ci — вимикає інтерактивність, не оновлює snapshots автоматично, падає при застарілих snaps;
• --runInBand — послідовний запуск (оптимально для дешевих runner-ів);
• --forceExit — примусове завершення при завислих handles.

Go: вбудований testing

---
- name: Run unit tests
  run: go test ./... -v -count=1 -coverprofile=coverage.out
- name: Convert coverage
  run: go tool cover -func=coverage.out

-count=1 вимикає кешування — у CI завжди свіжий прогін.

Як прискорити прогін тестів?

На проектах із сотнями тестів прогін займає 5–10 хвилин. Для прискорення використовуємо паралелізацію. Порівняння на прикладі 500 тестів:

Jest sharding — розбиваємо тест-сьют на кілька jobs. Кількість шардів обирається так, щоб кожен запускався в окремому runner. Для TypeScript-проекту з 1000 тестів це скоротило час прогону з 12 хвилин до 3,5.

pytest-xdist: pytest -n auto tests/unit/ використовує всі доступні ядра. На великому Python-моноліті ми прискорили прогін у 4 рази.

Go test: достатньо додати t.Parallel() у код тесту та вказати -parallel 4.

Кешування залежностей критичне: actions/setup-node з cache: 'npm' або actions/setup-python з cache: 'pip' економлять по 1–2 хвилини на прогоні.

Ефект від впровадження автоматизації Unit-тестів

Test Summary — що це дає?

GitHub Actions підтримує Test Summary — таблицю результатів тестів прямо в Summary пайплайну. Рев'юер бачить: 47 passed, 2 failed — і одразу посилання на впавші тести. Налаштовується action:

- name: Test Summary uses: test-summary/action@v2 if: always() with: paths: "reports/**/*.xml" 

Більше не потрібно скролити логи в пошуках помилки.

Матриця версій

Для бібліотек критично тестувати на кількох версіях рантайму. Це виявляє несумісності, які інакше виявляються лише у користувачів. Наприклад, перевірка на 3 версіях Node.js виявляє 20% несумісностей, які пропустила б єдина версія.

strategy: matrix: node-version: ['18', '20', '22'] os: [ubuntu-latest, windows-latest] 

Блокування мержу при падінні тестів

У налаштуваннях репозиторію додаємо test job як Required Status Check. GitHub не дасть змержити PR, доки цей статус не зелений. Це організаційна гарантія — не залежить від дисципліни розробників.

Що входить у роботу

• Аудит поточного CI/CD та тестової інфраструктури;
• Написання або доопрацювання pipeline-скриптів (YAML, Groovy, HCL);
• Інтеграція кешування та паралелізації;
• Налаштування Test Summary та JUnit-звітів;
• Підключення покриття коду з пороговими значеннями;
• Аналіз flaky-тестів та налаштування autoretries;
• Документація по pipeline та runbook для розробників;
• Навчання команди (1 годинна сесія);
• Гарантія працездатності протягом 30 днів після здачі.

Типові помилки при налаштуванні

1. Відсутність --ci у Jest — snapshots оновлюються автоматично, ламаючи тести;
2. Забувають завантажувати артефакти зі звітами навіть при падінні (if: always());
3. Не вимикають кешування тестів у Go (пропускають -count=1);
4. Використовують один runner для всіх задач — без матриці паралелізація не працює;
5. Не налаштовують Required Status Checks — мерж можливий без зелених тестів.

Уникнути цих проблем допоможе наш досвід: у кожному проекті ми фіксуємо runbook і проводимо postmortem-аналіз. Отримайте консультацію — напишіть нам. Зв'яжіться для оцінки вашого проекту — ми підготуємо пропозицію за 1 день.