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

Представьте: вы запускаете тесты перед релизом, а половина падает с ошибками подключения к БД или зависает из-за конкурентных запросов. Знакомо? Чаще всего проблема не в коде, а в тестовом окружении — оно сконфигурировано на скорую руку, без изоляции и повторяемости. В таких случаях вы тратите часы на отладку инфраструктуры вместо тестирования нового функционала. Это напрямую влияет на скорость релизов: команды с качественным тестовым окружением выкатывают изменения в 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 часа).

После сдачи вы получите репозиторий, готовый к тестированию на каждом коммите. Свяжитесь с нами — мы оценим ваш проект и предложим сроки. Получите консультацию по настройке тестового окружения уже сегодня.

Этапы настройки тестового окружения

Экономия времени и снижение затрат на поддержку — результат, который вы получите. Закажите настройку тестового окружения и убедитесь в стабильности тестов.