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