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.