My tests (or the tests I'm about to add) need a database, and I want hard guarantees they can never touch development or production data. Set up test database isolation: 1. Create a dedicated test database configuration, selected by an environment variable or config flag that only the test runner sets. 2. Add a startup guard: if the test runner is pointed at a database whose name doesn't clearly mark it as a test database (for example, containing `_test` or a similar convention), refuse to run and print a loud error. This guard matters more than anything else in this task. 3. Give tests a clean slate: either truncate/reset the test database between test files, or wrap each test in a transaction that rolls back. Pick whichever fits my database and ORM and explain the tradeoff briefly. 4. Make sure my schema or migrations run against the test database automatically before the suite runs, so a fresh checkout can run tests without manual setup. Check my existing seed or fixture scripts too. Any script that wipes or seeds data must have the same test-only guard. When done, show me the config flow: how the test runner picks its database, and prove the guard fires by showing me what happens if I deliberately point it at the wrong database.