Налаштування тестового середовища для веб-проекту: покрокове керівництво

Уявіть: ви запускаєте тести перед релізом, а половина падає з помилками підключення до БД або зависає через конкурентні запити. Знайомо? Найчастіше проблема не в коді, а в тестовому середовищі — воно сконфігуроване нашвидкуруч, без ізоляції та відтворюваності. У таких випадках ви витрачаєте години на відлагодження інфраструктури замість тестування нового функціоналу. Це безпосередньо впливає на швидкість релізів: команди з якісним тестовим середовищем викочують зміни в 2-3 рази частіше.

Ми налаштовуємо середовище так, щоб тести літали: Docker Compose з тимчасовими базами в RAM (tmpfs), транзакції після кожного кейсу та CI/CD, який ганяє паралельні джоби за хвилини. У результаті — стабільні тести, які виконуються за 2-3 хвилини замість звичайних 15-20. Наша команда має 8 років досвіду в цій галузі — ми налаштували тестові середовища для 50+ веб-проектів. Економія часу розробників після нашого налаштування досягає 60%.

Чому ізоляція тестового середовища критична?

Без ізоляції тести впливають один на одного: один видаляє запис, а інший його чекає. Або черга листів переповнюється, і асерти падають. Наші інженери використовують два перевірених підходи:

Другий варіант надійніший, але довший — тому ми використовуємо флаг <env name="DB_CONNECTION" value="sqlite"/> з :memory: для модульних тестів і окремий контейнер Postgres для інтеграційних. Так досягається баланс швидкості та ізоляції.

Як ми налаштовуємо Docker Compose для тестів?

Ми пишемо окремий docker-compose.test.yml, який піднімає копію продакшен-середовища, але з тестовими параметрами: синхронні черги (QUEUE_CONNECTION=sync), перехоплення листів (MAIL_MAILER=array) і кеш у пам'яті (CACHE_DRIVER=array). Ключова фішка — база даних на tmpfs (файлова система в RAM): це прискорює міграції та вибірки в 3-5 разів.

---
# docker-compose.test.yml
services:
  app:
    build:
      context: .
      target: test
    environment:
      APP_ENV: testing
      DB_HOST: db
      DB_DATABASE: testdb
      REDIS_HOST: redis
      QUEUE_CONNECTION: sync # черги синхронно в тестах
      MAIL_MAILER: array # перехоплення листів у масив
      CACHE_DRIVER: array # кеш у пам'яті
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: testdb
      POSTGRES_USER: test
      POSTGRES_PASSWORD: test
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U test"]
      interval: 5s
      timeout: 3s
      retries: 5
    tmpfs:
      - /var/lib/postgresql/data # БД в RAM — швидше
  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s

Як конфігурувати Laravel для тестів?

У phpunit.xml ми задаємо оточення — це гарантує, що жоден тест випадково не смикне продакшен-базу. Приклад конфігурації для тестової бази даних:

// phpunit.xml
<php>
  <env name="APP_ENV" value="testing"/>
  <env name="DB_CONNECTION" value="sqlite"/>
  <env name="DB_DATABASE" value=":memory:"/>
  <env name="CACHE_DRIVER" value="array"/>
  <env name="SESSION_DRIVER" value="array"/>
  <env name="QUEUE_CONNECTION" value="sync"/>
  <env name="MAIL_MAILER" value="array"/>
</php>

Базовий TestCase використовує RefreshDatabase — він перестворює БД перед кожним тестом. Для тестів з HTTP-клієнтом (наприклад, $this->post()) транзакції можуть не відкотити дані, тому ми віддаємо перевагу RefreshDatabase.

// Базовий TestCase з транзакціями
abstract class TestCase extends BaseTestCase
{
    use RefreshDatabase;

    protected function setUp(): void
    {
        parent::setUp();
        $this->withoutVite();
        $this->seed(TestDatabaseSeeder::class);
    }
}

Детальніше про тестування в Laravel: Laravel Testing.

Фабрики тестових даних

Щоб тести були реалістичними, ми пишемо фабрики для ключових моделей. Приклад UserFactory з ролями:

// database/factories/UserFactory.php
class UserFactory extends Factory
{
    public function definition(): array
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => Hash::make('password'),
        ];
    }

    public function admin(): static
    {
        return $this->afterCreating(fn(User $user) => $user->assignRole('admin')
        );
    }

    public function unverified(): static
    {
        return $this->state(['email_verified_at' => null]);
    }
}

Використовуємо в тестах: $user = User::factory()->admin()->create(); — мінімум коду, максимум виразності.

CI/CD — GitHub Actions

Налаштовуємо два воркфлоу: для юніт-тестів (SQLite, швидкі) та для інтеграційних (Postgres у сервісі). Паралельний запуск скорочує загальний час прогону в 2-3 рази.

---
name: Tests
on: [push, pull_request]
jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: 'sqlite3'
      - run: composer install --no-interaction
      - run: php artisan test --parallel --testsuite=Unit
  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: testdb
          POSTGRES_PASSWORD: test
        ports:
          - '5432:5432'
        options: --health-cmd pg_isready --health-interval 5s
    env:
      DB_CONNECTION: pgsql
      DB_HOST: localhost
      DB_DATABASE: testdb
      DB_PASSWORD: test
    steps:
      - uses: actions/checkout@v4
      - run: composer install
      - run: php artisan test --testsuite=Feature

Що входить у налаштування тестового середовища

Ми готуємо під ключ:

• Проектування архітектури тестової середи (Docker + CI).
• Налаштування Docker Compose із продакшен-залежностями, але тестовими налаштуваннями.
• Конфігурацію PHPUnit / Pest із паралельним запуском (--parallel).
• Фабрики даних (UserFactory, ProductFactory) зі станами під сценарії.
• Моки зовнішніх сервісів (Stripe, SendGrid, будь-які API).
• Інтеграцію з GitHub Actions (юніт + інтеграційні джоби).
• Документацію щодо запуску та доопрацювання тестів.
• Навчання команди (воркшоп на 2 години).

Після здачі ви отримаєте репозиторій, готовий до тестування на кожному коміті. Зв'яжіться з нами — ми оцінимо ваш проект і запропонуємо терміни. Отримайте консультацію з налаштування тестового середовища вже сьогодні.

Етапи налаштування тестового середовища

Економія часу та зниження витрат на підтримку — результат, який ви отримаєте. Замовте налаштування тестового середовища та переконайтеся в стабільності тестів.