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

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

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

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

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