Root-cause fix for cross-file DB pollution in the vitest suite, which
surfaced as intermittent FK-violation failures once the suite hit 12
test files. tests/setup.ts previously mutated the global
process.env.DATABASE_URL and relied on src/lib/prisma.ts's singleton
picking it up, which is racy across files sharing a worker process
(process.env isn't reset between files even though Vitest resets each
file's module registry). fileParallelism: false only masked this.
Now each test file's own tests/setup.ts creates its own throwaway
Postgres database and vi.mock()s "@/lib/prisma" with a dedicated
PrismaClient constructed via the explicit datasourceUrl option, so no
mutable state is shared between files and fileParallelism can go back
to its default (true).
Verified with 4 consecutive full `npm test` runs (327/327 passing each
time) and no leftover throwaway databases after each run.
Vitest's default glob isn't excluded for .claude/, so a sibling worktree
under .claude/worktrees/ (e.g. worktree-ui-basic) got silently collected
and run against this repo's current src/ via the "@" alias, doubling the
test count and running a stale test file against current code under a
shared identity. Found by an independent test-runner pass while verifying
the Assignment transfer fix.
Each test file gets its own throwaway Postgres database by mutating
process.env.DATABASE_URL in tests/setup.ts's beforeAll. That per-file
DB switch is not safe under Vitest's default parallel file execution:
timing between two files' beforeAll/query calls can interleave enough
that both end up issuing real queries against the same throwaway DB.
This was invisible before because no two test files shared tables
with a real FK between them. It became visible once Request gained a
real FK to Employee: tests/employees.test.ts and tests/requests.test.ts
started intermittently deleting/reading each other's rows (FK
violations on deleteMany, wrong row counts), reproducible on every
run. Setting fileParallelism: false makes each file run to completion
before the next starts, so the per-file throwaway DB is genuinely
private. Confirmed: 31/31 tests pass reliably under plain npm test
(previously reproducibly 4 failing).
toanhoang
toanhoang