Інтеграційні тести часто потребують справжньої PostgreSQL, MySQL або Redis. Але встановлювати ці сервіси прямо на сервер CI незручно: конфігурація розповзається, середовище стає важчим, а помилки важче повторити.
Service container вирішує це простіше: він запускає тимчасовий сервіс поруч із вашим тестовим завданням, а після завершення тестів прибирає його разом із середовищем.
Що таке service container
Service container у CI - це допоміжний контейнер, який стартує поруч із основним завданням тестів. Найчастіше його використовують для бази даних, кеша або черги повідомлень, які потрібні тестам, але не мають бути встановлені на сам сервер-виконавець.
Важлива різниця: service container не є вашим застосунком і не є контейнером для бойового середовища. Це тимчасова частина тестового середовища.
Коли це корисно
- Коли інтеграційні тести мають працювати з реальною PostgreSQL, MySQL або Redis.
- Коли ви хочете повторюваний CI без ручного встановлення залежностей на сервер.
- Коли локальна поведінка і CI мають бути максимально схожими.
- Коли треба перевірити міграції, SQL-запити або підключення до кеша в умовах, схожих на реальні.
Як це працює
Основна ідея проста:
- CI запускає основне тестове завдання.
- Поруч стартує service container, наприклад PostgreSQL.
- Тести підключаються до нього через внутрішню мережу або службову назву хоста.
- Після завершення завдання середовище знищується.
Під час запуску важливо не тільки описати контейнер, а й дочекатися його готовності. База даних може прийняти процес, але ще не бути готовою до підключення. Саме тому health check або retry-логіка часто важливіші за сам факт старту контейнера.
Де новачок це побачить
- GitHub Actions
services - GitLab CI
services - Docker Compose, якщо процес CI імітує кілька сервісів локально
У всіх цих випадках логіка однакова: основний тестовий процес отримує готову базу даних без додаткової ручної інсталяції.
Типові помилки
- Плутати service container із контейнером, який потім поїде у бойове середовище.
- Думати, що контейнер автоматично готовий до підключення без health check або очікування старту.
- Використовувати занадто важку конфігурацію для простих тестів.
- Забувати про змінні оточення, порти та логін/пароль для тестової бази.
- Писати тести так, ніби база вже має попередній стан, хоча контейнер зазвичай стартує чистим.
Що перевірити перед запуском
- Чи потрібен вам саме окремий сервіс, а не in-memory заміна або test double.
- Чи тестам достатньо тимчасової бази.
- Чи є health check або retry-логіка для очікування старту сервісу.
- Чи однакові назви хостів і змінних у локальному запуску та CI.
- Чи міграції й тестові дані створюються в межах кожного запуску.
Короткий приклад
Якщо ваш застосунок тестує SQL-запити, service container з PostgreSQL дозволяє:
- стартувати чисту базу на кожен запуск CI;
- проганяти міграції перед тестами;
- отримувати передбачувані результати без ручного налаштування сервера.
Якщо тестам потрібна лише перевірка бізнес-логіки без реальної бази, service container може бути зайвим. Але коли треба перевірити справжнє підключення, міграції або SQL-поведінку, це зазвичай чистіший варіант, ніж налаштовувати базу вручну на сервері CI.
Підсумок
Service container корисний, коли тестам потрібен реальний сервіс поруч, але ви не хочете робити сервер CI важким і залежним від ручних налаштувань. Для стабільного запуску перевірте три речі: як тести знаходять сервіс, коли сервіс стає готовим і чи кожен запуск починається з чистого тестового стану.
Короткий чеклист
- Я розумію, який сервіс потрібен тестам і навіщо.
- Я знаю, як тестове завдання CI знайде service container у мережі.
- Я перевірив порти, назви хостів, змінні оточення й тестові облікові дані.
- Я додав health check або retry-логіку, щоб тести не стартували зарано.
- Я не використовую важкий реальний сервіс там, де достатньо простішої тестової заміни.
Prompt Pack: перевірити service container для тестів у CI
Допоможи перевірити, чи варто запускати базу даних або кеш як service container у CI для цього тестового сценарію. Вхідні дані: - CI-система: GitHub Actions, GitLab CI, Jenkins, CircleCI або інша; - стек застосунку: мова, фреймворк, інструмент запуску тестів; - який сервіс потрібен тестам: PostgreSQL, MySQL, Redis, RabbitMQ або інший; - тип тестів: інтеграційні, end-to-end, міграції, API-тести; - які змінні оточення, порти й облікові дані вже налаштовані; - чи є health check, retry-логіка або очікування готовності сервісу. Поверни: 1. чи підходить тут service container, чи краще обрати in-memory заміну або test double; 2. мінімальну схему запуску сервісу поруч із тестами; 3. список змінних, портів і назв хостів, які треба узгодити; 4. 3-5 типових помилок, які можуть зламати процес CI; 5. короткий план перевірки після першого запуску. Формат: рішення, мінімальна конфігурація, що перевірити, типові ризики.