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

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

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

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

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