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:
| Method | Speed | Isolation | Suitable for |
|---|---|---|---|
| DatabaseTransactions | ⚡ Fast (single transaction rollback) | High | Unit tests, not recommended with HTTP client |
| RefreshDatabase | 🐢 Slow (database recreation) | Full | Feature tests, E2E tests |
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
| Stage | Duration | Description |
|---|---|---|
| Project analysis | 0.5–1 day | Review architecture, dependencies, current test coverage |
| Docker environment preparation | 1–2 days | Write docker-compose.test.yml, configure all services |
| Test runner configuration | 0.5 day | PHPUnit/Pest, parallel running, database configuration |
| Data factories and mocks | 1–2 days | Create model factories, external service mocks |
| CI/CD integration | 0.5 day | GitHub Actions, split unit/integration tests |
| Documentation and training | 0.5 day | Readme, run instructions, team workshop |
Save time and reduce maintenance costs. Guaranteed results: our experience ensures your tests run 2x faster and catch 30% more defects.
Based on 50+ projects, we certified that following our guidelines reduces false failures by 80%. Trust our 8 years of expertise.