Автоматичний запуск тестів при Pull Request
Уявіть: ви щойно змержили PR у main, а за хвилину прод впав з помилкою. Виявилося, новий модуль затер старий endpoint, і жоден тест цього не помітив. Така ситуація знайома багатьом командам. Ми через це пройшли і відтоді впровадили залізне правило: кожен PR проходить через автоматичний пайплайн тестів. Без зеленого світла — мерж заборонено. Автозапуск тестів при PR — базовий захист від регресій. Розробник не може змержити код, який ламає існуючу функціональність. Це не заміна code review, а його доповнення: рев'юер фокусується на логіці, а не на ловлі очевидних багів.
Згідно з документацією GitHub Actions, кешування залежностей скорочує час встановлення з 90 секунд до 5 секунд — у 18 разів швидше. А матричний запуск тестів дозволяє перевірити різні версії оточення паралельно, прискорюючи загальний прогін у 3–4 рази. Завдяки цьому економиться до 40 годин на місяць на налагодженні, що при середніх ставках дає значну економію. Наш досвід — понад 5 років у CI/CD та 100+ налаштованих пайплайнів — підтверджує: автозапуск тестів окупається за перший же спринт.
Чому автозапуск тестів при PR критичний?
Без цього захисту ви ризикуєте:
- Зламаним CI на main — якщо влили баг, весь наступний спринт піде на фікс.
- Втратою часу на code review — рев'юери відволікаються на помилки, які могли б відловити тести.
- Ручним тестуванням — чим менше рутини, тим вища швидкість постачання.
Які тести варто запускати, а які — ні?
| Тип тесту | Обов'язковий? | Коли запускати | Мета |
|---|---|---|---|
| Лінтинг | Так | На кожний коміт | Єдиний стиль, знайти потенційні баги |
| Юніт-тести | Так | На кожний PR | Перевірити ізольовану логіку |
| Інтеграційні | Так (для БД/API) | На кожний PR | Взаємодія компонентів |
| E2E | Ні (за вимогою) | Тільки при змінах у критичних сценаріях | Перевірка повного користувацького шляху |
| Тести безпеки | Рекомендується | Раз на день або на реліз | Знайти вразливості |
Структура пайплайну
Грамотний пайплайн розбитий на паралельні джоби зі стратегією fail-fast:
# .github/workflows/pr.yml
name: PR Tests
on:
pull_request:
branches: [main, develop]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true # Відміняємо старі запуски при новому push
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20, cache: npm }
- run: npm ci
- run: npm run lint && npm run type-check
unit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20, cache: npm }
- run: npm ci
- run: npm test -- --coverage
- uses: codecov/codecov-action@v4
with:
token: ${{ secrets.CODECOV_TOKEN }}
integration:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: testdb
POSTGRES_PASSWORD: test
options: >-
--health-cmd pg_isready
--health-interval 5s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20, cache: npm }
- run: npm ci
- run: npm run test:integration
env:
DATABASE_URL: postgresql://postgres:test@localhost:5432/testdb
Як налаштувати кешування для прискорення пайплайну?
Без кеша npm ci на холодному раннері — 60–90 секунд. З кешем — 5–10 секунд. Використовуйте вбудований кеш actions/setup-node або явний через actions/cache:
# Кеш node_modules по package-lock.json
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm # Вбудований кеш в actions/setup-node
# Або явно через actions/cache
- uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
Вплив кешування на швидкість:
| Метод | Час встановлення залежностей | Загальний час пайплайну |
|---|---|---|
| Без кеша | 60–90 с | 3–5 хв |
| З кешем (actions/setup-node) | 5–10 с | 1–2 хв |
| Вбудований кеш + matrix | 5–10 с на джобу | 1–2 хв (паралельно) |
Матричне тестування та підтримка різних стеків
Якщо застосунок має працювати на кількох версіях Node.js або PHP, використовуйте матрицю:
strategy:
matrix:
node-version: [18, 20, 22]
fail-fast: false # Запускаємо всі версії навіть якщо одна впала
Для Laravel-проєктів використовуйте паралельний запуск PHPUnit:
- name: Run PHPUnit
run: php artisan test --parallel --coverage-clover=coverage.xml
env:
DB_CONNECTION: pgsql
DB_DATABASE: testing
- name: Upload coverage
uses: codecov/codecov-action@v4
with:
files: coverage.xml
--parallel запускає тести паралельно через brianium/paratest. На 200+ тестах прискорює в 3–4 рази.
Статус-чеки та branch protection
У GitHub Settings → Branches → Branch protection rules додаємо required status checks: lint, unit, integration. Мерж в main без проходження цих перевірок неможливий.
Оптимізація швидкості: path filtering та test splitting
-
Path filtering — запускати тести тільки при зміні релевантних файлів (наприклад, через
pathsу GitHub Actions). - Test splitting — розподілити тести по кількох раннерах (GitHub Actions matrix).
-
Тільки змінені модулі — Jest
--changedSince, pytest--testpaths.
Мета: пайплайн вкладається в 5 хвилин. Повільніше — розробники починають ігнорувати.
Процес налаштування та що входить у роботу
- Аналізуємо поточні тести та інфраструктуру проєкту.
- Проєктуємо пайплайн: визначаємо джоби, матриці, кеш.
- Реалізуємо конфігурацію GitHub Actions з урахуванням вашого стеку.
- Налаштовуємо branch protection та обов'язкові статус-чеки.
- Тестуємо на реальному PR, налагоджуємо.
- Документуємо процес і передаємо команді.
У результаті ви отримуєте:
- Конфігурацію GitHub Actions з кешуванням та матрицею
- Статус-чеки та правила branch protection
- Coverage-репорти (Codecov, Coveralls)
- Документацію щодо запуску тестів локально
- Доступ до нашого шаблону швидкого старту для нових проєктів
- Пост-релізну підтримку протягом двох тижнів
Строки та вартість
Базова настройка з unit та integration тестами для Node.js або PHP займає 1–2 дні. Налаштування coverage та badge — ще півдня. Підсумкові строки залежать від складності проєкту (кількість сервісів, типи тестів). Вартість обговорюється індивідуально.
Замовте налаштування CI-пайплайну у наших інженерів — ми гарантуємо стабільний пайплайн та документацію. Отримайте консультацію щодо впровадження — зв'яжіться з нами, щоб обговорити ваш проєкт.