Testing

This page documents the verification infrastructure that actually exists in the repositories — nothing more.

Backend test suites (`dps-code-api`)

The API repository contains executable contract suites. They import the real Flask app but replace Supabase with an in-memory fake, so they exercise route logic, gates, and response contracts without a database:

Suite	Covers
`report_route_tests.py`	Report create/list/update/delete routes, actions, notes/evidence/timeline, contact, gates, error mapping
`punishment_route_tests.py`	Punishment create/edit/revoke, discipline queue, user-lookup flow, permissions
`training_route_tests.py`	Training auth/API-key rejection, role gates, session lifecycle, action idempotency, engine evaluation, controls, realtime config/token
`authz_tests.py`	Clearance/rank gates, assignment matching, admin gating
`db_access_tests.py`	Serializers, identifier scrubbing, profile normalization
`action_queue_tests.py`	Queue helpers, claim/requeue logic, error mapping
`event_service_tests.py`	Event recording, taxonomy validation
`agents_service_tests.py` / `admin_service_tests.py`	Agent/admin contracts
`contact_threads_tests.py`	Contact serialization
`oauth_service_tests.py`	OAuth helpers, return_to validation
`health_service_tests.py`	Health payload building
`environment_tests.py`	Environment config isolation, session binding, ingress resolution
`datetime_unix_tests.py`	JS-date → Unix timestamp parsing
`erlc_relay_route_tests.py` / `erlc_relay_failover_tests.py` / `erlc_relay_failover_smoke.py`	ER:LC relay route, failover ordering, circuit breaker
`training_runtime_tests.py`	Session payload assembly, elapsed time, role filters
`security_hardening_tests.py`	URL validation, body limits, identifier bounds, CORS

Run a suite with the API's Python environment:

bash

cd dps-code-api
source .venv/bin/activate
python report_route_tests.py
python training_route_tests.py

Limitations: the fake Supabase proves route logic and response contracts, not actual PostgREST query behavior, RLS execution, or database transaction semantics. SQL-level behavior (row locks, error tags, privileges) is verified against a real PostgreSQL project when migrations are applied.

Frontend checks (`ecc-dps-dashboard`)

Command	What it does
`npm run build`	`tsc -b` (project typecheck) then `vite build` (production bundle)
`npm run lint`	ESLint over the repository
`npm run smoke:typecheck`	`tsc --noEmit -p tsconfig.playwright.json` (Playwright specs)
`npm run smoke`	Playwright suite against the configured base URL
`npm run smoke:login`	Interactive production session capture (saves `playwright/.auth/state.json`)

Interpreting failures:

npm run build failures are type errors or bundling problems — fix them before anything else; the build is the project's primary gate.
The repository has known pre-existing ESLint debt: lint failures unrelated to your change are tracked separately and do not gate release (per the project's recent release work). Do not "fix" unrelated lint noise in the same change.
npm run smoke runs against production (https://eccdps.org by default) with a saved auth state — it requires a valid saved session and stable production fixtures, and is not part of a clean-checkout flow.

Playwright suites (`tests/smoke/`)

Spec	Covers
`smoke.spec.ts`	Dashboard stats, docket sorting/filters/pagination, detail rendering, queue sections, audit log
`training.spec.ts`	Trainer dashboard, new-session modal, history, dockets, recovery panel
`realtime-join.spec.ts`	API-minted Realtime token + private channel joins (asserts `SUBSCRIBED`)
`realtime-live.spec.ts`	Live trainer→trainee transition without refresh (creates + aborts an isolated session)
`agent-management.spec.ts`	Agent-management flows

Additional diagnostic/E2E scripts live in playwright/ (trainee flows, pause/abort, grading, recovery behavior). Some are production workflow harnesses that create disposable training sessions — treat them as diagnostics, not stable unit tests.

Database / RPC tests

There is no separate SQL test harness in the repository. Verification of migrations and RPCs is performed by:

Applying the full chain 000–034 in order to a scratch PostgreSQL 16 project;
exercising each RPC's happy path + documented error tags and privilege posture (public/anon/authenticated denied, service_role allowed);
checking RLS behavior with browser-role JWTs where relevant (migrations 026/027 document their live verification).

What is not covered (known gaps)

No broad frontend unit/component tests (React components and the Realtime hook lifecycle are covered only via Playwright).
Production smoke tests depend on saved OAuth state and existing data.
The API contract suites do not prove real database transaction/RLS behavior.
No CI workflow is configured in the repositories — verification runs locally/manually.

Testing ​

Backend test suites (dps-code-api) ​

Frontend checks (ecc-dps-dashboard) ​

Playwright suites (tests/smoke/) ​

Database / RPC tests ​

What is not covered (known gaps) ​

Related reading ​