# Testing — database isolation

## TL;DR

Tests run `resetDb()` → **`DROP SCHEMA public CASCADE`**. They MUST run against a
dedicated **`void_test`** database, never the prod `void` DB. This is enforced
in code (`tests/helpers/setup.js` throws if the resolved URL still targets
`/void`).

## Why

The void2 Postgres cluster on `192.168.1.215` (CT 310) is shared: the prod app
(CT 311) and dev runs both use it. The dev `DATABASE_URL` points at the prod
`void` database. Before isolation, `npm test` wiped production data on every run
(spaces/tasks/etc. gone; migrations + the seeded `companion` agent re-created by
`migrateUp`, which masked the damage).

## Setup (already done — 2026-06-01)

1. **`void_test` database** created on the `.215` cluster, owned by `void`:
   ```sql
   -- run while connected to the `void` db (the `postgres` maintenance db is
   -- not reachable from the dev box per pg_hba.conf):
   CREATE DATABASE void_test OWNER void;
   ```
2. **`pg_hba.conf`** on CT 310 (`/etc/postgresql/16/main/pg_hba.conf`) — added a
   rule mirroring the `void` one, then `systemctl reload postgresql@16-main`:
   ```
   host    void_test    void    192.168.1.0/24    scram-sha-256
   ```
3. **`tests/helpers/setup.js`** (vitest `setupFiles`) forces the test DB and
   guards against prod:
   - uses `TEST_DATABASE_URL` if set, else derives it by swapping `/void` →
     `/void_test` in `DATABASE_URL`;
   - **throws** if the resolved URL still points at `/void`.
4. Dev **`.env`** has `TEST_DATABASE_URL=postgres://void:…@192.168.1.215:5432/void_test`.

## Running tests

```bash
npm test          # vitest; binds the pool to void_test via setup.js
```

`resetDb()` + `migrateUp()` rebuild `void_test`'s schema each run. Prod `void`
is never touched. The guard makes a misconfiguration fail loudly instead of
silently wiping prod.

## Note

`.env` (incl. `TEST_DATABASE_URL`) is git-ignored and not deployed — this is a
dev-box concern only. Prod (CT 311) never runs the test suite.