Safe Test Environments and Isolation

Choose a disposable target

Common choices include an ephemeral container, a per-job database/schema on a shared test server, or a managed non-production instance. Select the target engine and version that match the application's support matrix. Confirm network, extensions, collation, timezone, and configuration differences that can affect outcomes.

• Use a clearly named, isolated test database or schema.
• Use separate credentials with only the permissions the tests need.
• Never load production secrets into test jobs.
• Use synthetic or approved masked data—not an uncontrolled production copy.
• Set connection, statement, and job timeouts appropriate to the test.

Fail closed on the target

Before destructive setup or cleanup, assert the target environment explicitly. Do not infer “test” from an optional default, a developer's laptop, or a database name alone.

-- Example guard in test setup (adapt to your driver/config):
if APP_ENV != "test":
    stop_before_database_reset()
if DATABASE_HOST not in approved_test_hosts:
    stop_before_database_reset()
if DATABASE_NAME not in approved_test_databases:
    stop_before_database_reset()

Application pseudocode above is intentionally not executable SQL. Put equivalent guards in the test runner/configuration, check errors visibly, and require a deliberate opt-in before creating or dropping a database.

Make setup and teardown reliable

1. Provision the target from version-controlled infrastructure or a pinned image.
2. Apply schema migrations from a clean starting point.
3. Load deterministic fixtures and verify expected setup counts.
4. Run tests with a unique run ID where concurrent jobs share resources.
5. Clean up only objects owned by that run; preserve logs on failure.
6. Destroy ephemeral resources and confirm the teardown completed.

Environment parity checklist

Record database engine/version, extensions, migration revision, relevant parameters, locale/collation, timezone, and connection mode. Differences should be intentional and documented. Tests on SQLite alone, for example, cannot prove PostgreSQL-specific query or locking behavior.