package.json's jest config sets rootDir: "src" and testRegex: ".*\\.spec\\.ts$" with no testPathIgnorePatterns. src/database/escrow-fk-integrity.integration.spec.ts matches that same regex (it ends in .spec.ts) but, per its own doc comment, genuinely requires a live Postgres connection (synchronize: true against a real DataSource) — unlike every other .spec.ts file in the repo, which mocks its repositories.
In CI this is invisible because the "Run Unit & Integration Tests" step explicitly provides DATABASE_URL pointing at the workflow's postgres service container — so the step name already tacitly acknowledges two different test tiers are being run together. But a contributor running npm run test locally without DATABASE_URL set (e.g. before running docker compose up -d db, or simply not realizing one .spec.ts file among ~30 needs a database) gets a Postgres connection failure mixed into what looks like a fast, dependency-free unit test run, with no jest-level distinction between "this failed because of a real bug" and "this failed because you don't have a database running."
Consider a testPathIgnorePatterns (or a separate jest project/config) excluding *.integration.spec.ts from the default npm run test script, with its own npm run test:integration script that documents the DATABASE_URL requirement explicitly — mirroring how test:e2e already gets its own script and documented prerequisite in the README.
package.json's jest config setsrootDir: "src"andtestRegex: ".*\\.spec\\.ts$"with notestPathIgnorePatterns.src/database/escrow-fk-integrity.integration.spec.tsmatches that same regex (it ends in.spec.ts) but, per its own doc comment, genuinely requires a live Postgres connection (synchronize: trueagainst a realDataSource) — unlike every other.spec.tsfile in the repo, which mocks its repositories.In CI this is invisible because the "Run Unit & Integration Tests" step explicitly provides
DATABASE_URLpointing at the workflow'spostgresservice container — so the step name already tacitly acknowledges two different test tiers are being run together. But a contributor runningnpm run testlocally withoutDATABASE_URLset (e.g. before runningdocker compose up -d db, or simply not realizing one.spec.tsfile among ~30 needs a database) gets a Postgres connection failure mixed into what looks like a fast, dependency-free unit test run, with no jest-level distinction between "this failed because of a real bug" and "this failed because you don't have a database running."Consider a
testPathIgnorePatterns(or a separate jest project/config) excluding*.integration.spec.tsfrom the defaultnpm run testscript, with its ownnpm run test:integrationscript that documents theDATABASE_URLrequirement explicitly — mirroring howtest:e2ealready gets its own script and documented prerequisite in the README.