How to Configure a Test Environment for Web Projects: A Practical Guide

Imagine: you run tests before a release, and half of them fail with database connection errors or hang due to concurrent queries. Sound familiar? Often the issue isn't the code but the test environment—configured hastily, without isolation or repeatability. In such cases, you spend hours debugging infrastructure instead of testing new features. This directly impacts release velocity: teams with a solid test environment ship changes 2-3 times more frequently.

We set up environments that make tests fly: Docker Compose with temporary databases in RAM (tmpfs), transactions after each case, and CI/CD that runs parallel jobs in minutes. The result is stable tests that complete in 2-3 minutes instead of the usual 15-20. Our team has 8 years of experience in this area—we've configured test environments for 50+ web projects. Developer time savings after our setup reach 60% – that's over $5,000 per developer per year in regained productivity.

Why Test Environment Isolation Is Critical

Without isolation, tests affect each other: one deletes a record, another expects it. Or the email queue overflows and assertions fail. Our engineers use two proven approaches:

The second option is more reliable but slower—so we use the <env name="DB_CONNECTION" value="sqlite"/> flag with :memory: for unit tests and a separate Postgres container for integration tests. This balances speed and isolation.

How We Configure Docker Compose for Tests

We write a separate docker-compose.test.yml that spins up a copy of the production environment but with test parameters: synchronous queues (QUEUE_CONNECTION=sync), mail interception (MAIL_MAILER=array), and in-memory cache (CACHE_DRIVER=array). The key feature is the database on tmpfs (RAM filesystem): it speeds up migrations and queries by 3-5 times.

# 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 # queues synchronous in tests
      MAIL_MAILER: array # intercept mail to array
      CACHE_DRIVER: array # cache in memory
    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 # DB in RAM – faster
  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s

How to Configure Laravel for Tests

In phpunit.xml we set the environment—this ensures no test accidentally touches the production database. Example configuration for a test database:

<!-- 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>

A base TestCase uses RefreshDatabase—it recreates the database before each test. For tests with an HTTP client (e.g., $this->post()), transactions may not roll back data, so we prefer RefreshDatabase.

// Base TestCase with transactions
abstract class TestCase extends BaseTestCase
{
    use RefreshDatabase;

    protected function setUp(): void
    {
        parent::setUp();
        $this->withoutVite();
        $this->seed(TestDatabaseSeeder::class);
    }
}

More about testing in Laravel: Laravel Testing.

Test Data Factories

To make tests realistic, we write factories for key models. Example UserFactory with roles:

// 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]);
    }
}

Use in tests: $user = User::factory()->admin()->create();—minimal code, maximum expressiveness.

CI/CD — GitHub Actions

We set up two workflows: one for unit tests (SQLite, fast) and one for integration tests (Postgres service). Parallel execution reduces total run time by 2-3 times.

---
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

What's Included in the Test Environment Setup

We deliver a turnkey solution:

• Design of test environment architecture (Docker + CI).
• Docker Compose setup with production dependencies but test-specific settings.
• PHPUnit/Pest configuration with parallel execution (--parallel).
• Data factories (UserFactory, ProductFactory) with states for scenarios.
• Mocks for external services (Stripe, SendGrid, any API).
• Integration with GitHub Actions (unit + integration jobs).
• Documentation on running and extending tests.
• Team training (2-hour workshop).

Upon delivery, you'll have a repository ready to test on every commit. Contact us—we'll assess your project and provide timelines. Get a consultation on test environment setup today.

Test Environment Setup Stages

Save time and reduce maintenance costs.