Уявіть: ви запускаєте тести перед релізом, а половина падає з помилками підключення до БД або зависає через конкурентні запити. Знайомо? Найчастіше проблема не в коді, а в тестовому середовищі — воно сконфігуроване нашвидкуруч, без ізоляції та відтворюваності. У таких випадках ви витрачаєте години на відлагодження інфраструктури замість тестування нового функціоналу. Це безпосередньо впливає на швидкість релізів: команди з якісним тестовим середовищем викочують зміни в 2-3 рази частіше.
Ми налаштовуємо середовище так, щоб тести літали: Docker Compose з тимчасовими базами в RAM (tmpfs), транзакції після кожного кейсу та CI/CD, який ганяє паралельні джоби за хвилини. У результаті — стабільні тести, які виконуються за 2-3 хвилини замість звичайних 15-20. Наша команда має 8 років досвіду в цій галузі — ми налаштували тестові середовища для 50+ веб-проектів. Економія часу розробників після нашого налаштування досягає 60%.
Чому ізоляція тестового середовища критична?
Без ізоляції тести впливають один на одного: один видаляє запис, а інший його чекає. Або черга листів переповнюється, і асерти падають. Наші інженери використовують два перевірених підходи:
| Метод | Швидкість | Ізоляція | Підходить для |
|---|---|---|---|
| DatabaseTransactions | ⚡ Швидко (відкат однією транзакцією) | Висока | Unit-тести, тести з HTTP-клієнтом не рекомендуються |
| RefreshDatabase | 🐢 Повільно (перестворення БД) | Повна | Feature-тести, E2E-тести |
Другий варіант надійніший, але довший — тому ми використовуємо флаг <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 години).
Після здачі ви отримаєте репозиторій, готовий до тестування на кожному коміті. Зв'яжіться з нами — ми оцінимо ваш проект і запропонуємо терміни. Отримайте консультацію з налаштування тестового середовища вже сьогодні.
Етапи налаштування тестового середовища
| Етап | Тривалість | Опис |
|---|---|---|
| Аналіз проекту | 0.5–1 день | Вивчення архітектури, залежностей, поточного тестового покриття |
| Підготовка Docker-середовища | 1–2 дні | Написання docker-compose.test.yml, налаштування всіх сервісів |
| Конфігурація тест-ранера | 0.5 дня | PHPUnit/Pest, паралельний запуск, конфігурація бази даних |
| Фабрики даних і моки | 1–2 дні | Створення фабрик для моделей, моків зовнішніх сервісів |
| Інтеграція CI/CD | 0.5 дня | GitHub Actions, розділення юніт/інтеграційних тестів |
| Документація та навчання | 0.5 дня | Readme, опис запуску, воркшоп для команди |
Економія часу та зниження витрат на підтримку — результат, який ви отримаєте. Замовте налаштування тестового середовища та переконайтеся в стабільності тестів.