Files
OpenFrame/.env.test.example
T
yusufipk 6136817f75 fix(test): keep the suites off a developer's real database
bun loads a plain `.env` into process.env before anything runs, and
tests/helpers/env.ts read that as a deliberate export, so it beat `.env.test`
outright. `scripts/test.sh api` therefore pointed the api suites at whatever
deployment `.env` describes: `prisma db push --accept-data-loss` for the
schema, then a truncate of every table between tests. The e2e half was worse,
because playwright.config.ts built and started the app with that DATABASE_URL
and those R2 credentials, then wrote fixtures into it. CI never saw any of
this: a runner has no `.env`.

Three changes, in order of what each one catches:

- helpers/dev-env.ts drops the values bun copied out of a development env file,
  leaving `.env.test` to fill them. Only values that match the file
  character-for-character go, so a real export still wins and the per-suite
  databases of a parallel api run keep working.
- helpers/test-database.ts refuses a DATABASE_URL whose database name is not
  marked as a test one, at the single point every path into the setup passes
  through. This is the backstop, not the fix.
- playwright.config.ts blanks the variables a development env file defines and
  the config does not. Dropping them from process.env is not enough there:
  `next build` and `next start` run @next/env themselves and read the files
  again. That is also why a local e2e run could not build at all (a set
  DISABLE_RATE_LIMIT throws in lib/rate-limit.ts under NODE_ENV=production) and
  why auth.spec.ts failed on a machine with SMTP configured.

`scripts/test.sh` now creates `.env.test` from the committed example instead of
asking for a one-line copy, so the guard above is something nobody has to meet.
2026-07-26 15:49:19 +07:00

82 lines
4.1 KiB
Bash

# Environment for the `api` Vitest project. `scripts/test.sh` copies this to
# `.env.test` (gitignored) on the first api or e2e run, so there is usually
# nothing to do by hand.
#
# `tests/setup/db-global.ts` and `tests/setup/api.ts` both load this file (via
# `tests/helpers/env.ts`) before anything imports `@/lib/db`, which reads
# DATABASE_URL once at module load and memoizes the pool. An already-exported
# variable always wins over the file, so CI can override DATABASE_URL without
# editing anything. What bun autoloaded from a development `.env` does not count
# as exported and is dropped first, or that file would quietly win here and
# point the suites at a real deployment.
# ---------------------------------------------------------------------------
# DATABASE
# ---------------------------------------------------------------------------
# The default targets the container-to-container hostname, because the test
# runner itself runs in a container attached to the `openframe-test` network:
# podman compose -f docker-compose.test.yml up -d
# podman run --rm --network openframe-test -v "$PWD":/workspace:z -w /workspace \
# docker.io/oven/bun:alpine sh -c "bun run test:api"
DATABASE_URL="postgresql://openframe:openframe@postgres-test:5432/openframe_test?schema=public"
# From the host instead (psql, or a runner that is not on that network), use the
# published port:
# DATABASE_URL="postgresql://openframe:[email protected]:55432/openframe_test?schema=public"
#
# On GitHub Actions, where Postgres is a service container on the job network:
# DATABASE_URL="postgresql://openframe:openframe@localhost:5432/openframe_test?schema=public"
# ---------------------------------------------------------------------------
# AUTH
# ---------------------------------------------------------------------------
# `auth()` is mocked in tests, so NEXTAUTH_SECRET is only used for real work by
# lib/share-session.ts, which HMAC-signs the share cookies.
NEXTAUTH_URL="http://localhost:3000"
NEXTAUTH_SECRET="test-secret-not-used-for-anything-real"
NEXT_PUBLIC_APP_URL="http://localhost:3000"
# ---------------------------------------------------------------------------
# FEATURE FLAGS
# ---------------------------------------------------------------------------
# Stripe on, because that is what production runs and because it is what arms
# every billing gate: hasBillingAccess() short-circuits to `true` when the flag
# is off, which would silently neuter the whole access-control surface. Tests
# that want the self-hosted behaviour stub the flag off per test.
OPENFRAME_ENABLE_STRIPE="true"
# Dummy credentials so isStripeBillingEnabled() is true and getStripePriceId()
# does not throw. `@/lib/stripe` is module-mocked, so no request ever leaves.
STRIPE_SECRET_KEY="sk_test_openframe_dummy"
STRIPE_PRICE_ID="price_test_openframe_dummy"
STRIPE_WEBHOOK_SECRET="whsec_test_openframe_dummy"
OPENFRAME_REQUIRE_INVITE_CODE="true"
INVITE_CODE="test-invite"
# Direct-upload providers are deliberately left unconfigured, so
# isDirectFileUploadEnabled() is false by default. Suites that exercise the
# presigned-upload routes stub R2_* / BUNNY_* in per test.
# No proxy in front of the test runner, so getClientIp() returns 127.0.0.1.
TRUSTED_PROXY_MODE="none"
# Rate limits are DB-backed and keyed on the client IP, which is that same
# constant for every request in the suite. Left on, one test exhausting a
# window would make the next test's 429 look like a passing authorization
# check. tests/api/rate-limit.test.ts re-enables it with vi.stubEnv (the flag
# is read per call, not at import) and is the only place that asserts on it.
DISABLE_RATE_LIMIT="true"
# SMTP is configured on purpose: isEmailVerificationEnabled() is derived from
# these three variables, and with them unset the register/verify routes take a
# different branch than production does. `nodemailer` is module-mocked in
# tests/setup/api.ts, so nothing leaves the process; the messages are captured
# and assertable through tests/helpers/mail.ts.
SMTP_HOST="localhost"
SMTP_PORT="1025"
SMTP_USER="test"
SMTP_PASSWORD="test"
SMTP_FROM="OpenFrame Test <[email protected]>"
NODE_ENV="test"