Database/network tests are isolated from production data
Why it matters
Tests that write to a database without a separate test database URL will insert, update, and delete rows in the development database. Over time this pollutes developer workflows with synthetic data, breaks count-based assertions as rows accumulate, and creates the risk that a destructive test (deleteMany, truncate) runs against real data if configuration is accidentally shared across environments. ISO-25010:2011 recoverability requires that test execution be isolated from other system states.
Severity rationale
Low because the impact is typically pollution and flakiness rather than immediate data loss, unless a destructive query is involved.
Remediation
Create a .env.test file with a separate DATABASE_URL pointing to a dedicated test database. Reference it explicitly in vitest.config.ts or your test runner configuration so it's impossible to accidentally run tests against the dev database:
# .env.test
DATABASE_URL=postgresql://user:pass@localhost:5432/myapp_test
// vitest.config.ts
export default defineConfig({
test: {
env: { DATABASE_URL: process.env.TEST_DATABASE_URL ?? '' },
setupFiles: ['./tests/setup.ts'],
},
})
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Test Reality Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · reliability.recoverability — Recoverability (reliability sub-characteristic)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ai-slop-test-theater·automated