principletypescriptMajor
Test environment management: use env-specific config files and never hardcode URLs
Viewed 0 times
test environmentenv varsdotenv testbase urlenvironment isolationenv config
Problem
Tests hardcode
http://localhost:3000 or https://staging.example.com. Running the test suite against a different environment requires search-and-replace. Tests accidentally run against production because the wrong env var was set.Solution
Use a hierarchy of
.env.test, .env.ci, .env.staging files loaded by dotenv or the test runner. Define a BASE_URL env var consumed in all tests. Validate required env vars at test setup and fail loudly with a clear message if they are missing or point to production.Why
Environment config as code makes environment targeting explicit and auditable. Validating env vars at startup surfaces misconfiguration before tests run, avoiding confusing failures mid-suite. Never allow test env vars to point to production endpoints.
Gotchas
- Do not commit .env files with real credentials — use .env.test.example with placeholder values
- CI environments should inject secrets as environment variables, not as committed files
- Protect against production targeting by checking for known production domain patterns and throwing if detected
- Test isolation requires test databases and queues to be separate from production — validate this in the startup check
Revisions (0)
No revisions yet.