Load environment configs via a central map (`envConfigMap`), standardize timeouts (action 15s, navigation 30s, expect 10s, test 60s), emit HTML + JUnit reporters, and store artifacts under `test-results/` for CI upload. Keep `.env.example`, `.nvmrc`, and browser dependencies versioned so local and CI runs stay aligned.
## Rationale
Environment-specific configuration prevents hardcoded URLs, timeouts, and credentials from leaking into tests. A central config map with fail-fast validation catches missing environments early. Standardized timeouts reduce flakiness while remaining long enough for real-world network conditions. Consistent artifact storage (`test-results/`, `playwright-report/`) enables CI pipelines to upload failure evidence automatically. Versioned dependencies (`.nvmrc`, `package.json` browser versions) eliminate "works on my machine" issues between local and CI environments.
## Pattern Examples
### Example 1: Environment-Based Configuration
**Context**: When testing against multiple environments (local, staging, production), use a central config map that loads environment-specific settings and fails fast if `TEST_ENV` is invalid.
ignoreHTTPSErrors: true, // Allow self-signed certs in staging
},
});
```
```typescript
// playwright/config/production.config.ts - Production environment
import { defineConfig } from '@playwright/test';
import { baseConfig } from './base.config';
export default defineConfig({
...baseConfig,
retries: 3, // More retries in production
use: {
...baseConfig.use,
baseURL: 'https://example.com',
video: 'on', // Always record production failures
},
});
```
```bash
# .env.example - Template for developers
TEST_ENV=local
API_KEY=your_api_key_here
DATABASE_URL=postgresql://localhost:5432/test_db
```
**Key Points**:
- Central `envConfigMap` prevents environment misconfiguration
- Fail-fast validation with clear error message (available envs listed)
- Base config defines shared settings, environment configs override
-`.env.example` provides template for required secrets
-`TEST_ENV=local` as default for local development
- Production config increases retries and enables video recording
### Example 2: Timeout Standards
**Context**: When tests fail due to inconsistent timeout settings, standardize timeouts across all tests: action 15s, navigation 30s, expect 10s, test 60s. Expose overrides through fixtures rather than inline literals.
- Fixture-based override (`extendedTimeout`) for slow tests (preferred over inline)
- Per-assertion timeout override via `{ timeout: X }` option (use sparingly)
- Avoid hard waits (`page.waitForTimeout(3000)`) - use event-based waits instead
- CI environments may need longer timeouts (handle in environment-specific config)
### Example 3: Artifact Output Configuration
**Context**: When debugging failures in CI, configure artifacts (screenshots, videos, traces, HTML reports) to be captured on failure and stored in consistent locations for upload.
-`screenshot: 'only-on-failure'` saves space (not every test)
-`video: 'retain-on-failure'` captures full flow on failures
-`trace: 'on-first-retry'` provides deep debugging data (network, DOM, console)
- HTML report at `playwright-report/` (visual debugging)
- JUnit XML at `test-results/results.xml` (CI integration)
- CI uploads artifacts on failure with 30-day retention
- Custom fixture can capture console logs, network logs, etc.
### Example 4: Parallelization Configuration
**Context**: When tests run slowly in CI, configure parallelization with worker count, sharding, and fully parallel execution to maximize speed while maintaining stability.
// playwright/config/serial.config.ts - Serial execution for flaky tests
import { defineConfig } from '@playwright/test';
import { baseConfig } from './base.config';
export default defineConfig({
...baseConfig,
// Disable parallel execution
fullyParallel: false,
workers: 1,
// Used for: authentication flows, database-dependent tests, feature flag tests
});
```
```typescript
// Usage: Force serial execution for specific tests
import { test } from '@playwright/test';
// Serial execution for auth tests (shared session state)
test.describe.configure({ mode: 'serial' });
test.describe('Authentication Flow', () => {
test('user can log in', async ({ page }) => {
// First test in serial block
});
test('user can access dashboard', async ({ page }) => {
// Depends on previous test (serial)
});
});
```
```typescript
// Usage: Parallel execution for independent tests (default)
import { test } from '@playwright/test';
test.describe('Product Catalog', () => {
test('can view product 1', async ({ page }) => {
// Runs in parallel with other tests
});
test('can view product 2', async ({ page }) => {
// Runs in parallel with other tests
});
});
```
**Key Points**:
-`fullyParallel: true` enables parallel execution within single test file
- Workers: 1 in CI (stability), N-1 CPUs locally (speed)
- Sharding splits tests across multiple CI machines (4x faster with 4 shards)
-`test.describe.configure({ mode: 'serial' })` for dependent tests
-`forbidOnly: true` in CI prevents `.only()` from blocking pipeline
- Matrix strategy in CI runs shards concurrently
### Example 5: Project Configuration
**Context**: When testing across multiple browsers, devices, or configurations, use Playwright projects to run the same tests against different environments (chromium, firefox, webkit, mobile).