Testing

Coverage thresholds

Enforced via the root Vitest config (v8 coverage provider) — a run that drops below these fails:

Running the suite

# From the monorepo root — every workspace package, via Turborepo
pnpm test

# With coverage
pnpm test:coverage

# Frontend E2E (Playwright)
cd apps/web && pnpm test:e2e

Exercising the API directly

All examples assume the local dev stack (http://localhost:12002/api/v1).

Register & login

curl -X POST http://localhost:12002/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"Test123!@#","firstName":"Test","lastName":"User"}'
# 201 Created — returns the user object

curl -X POST http://localhost:12002/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"Test123!@#"}'
# 200 — access and refresh tokens issued (or an MFA challenge)

Breach-check on registration

curl -X POST http://localhost:12002/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{"email":"test2@example.com","password":"password123","firstName":"T","lastName":"U"}'
# 400 — "This password has appeared in a known data breach.
#        Please choose a different password."

Runs automatically against the HaveIBeenPwned k-anonymity API on every register and change-password call — no plaintext password ever leaves the server, only a hashed prefix. The check fails open (allows the request through) on a lookup timeout or HIBP outage, rather than blocking registration on a third-party dependency.

MFA — TOTP & WebAuthn

curl -X POST http://localhost:12002/api/v1/mfa/totp/generate \
  -H "Authorization: Bearer $TOKEN"
# Returns a QR code + secret

curl -X POST http://localhost:12002/api/v1/mfa/totp/enable \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"code":"123456"}'
# Returns one-time backup codes

curl -X POST http://localhost:12002/api/v1/mfa/webauthn/register/options \
  -H "Authorization: Bearer $TOKEN"
# Returns a WebAuthn challenge + registration options

Audit log integrity

curl http://localhost:12002/api/v1/audit-logs/<id>/verify \
  -H "Authorization: Bearer $ADMIN_TOKEN"
# { valid: true, entry: {...} }

curl "http://localhost:12002/api/v1/audit-logs/bulk-verify?resource=user" \
  -H "Authorization: Bearer $ADMIN_TOKEN"
# { total, validCount, invalidIds: [] }

Every entry carries an integrity hash computed at write time. Editing a row directly in the database (bypassing the API) makes that entry fail its next verify call — the check is on the stored data, not on request provenance.

Workflow execution

curl -X POST http://localhost:12002/api/v1/workflows \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"Test Workflow","enabled":true,"steps":[
        {"name":"Send Email","type":"email",
         "config":{"to":"test@example.com","subject":"Test","body":"Test email"}}
      ]}'
# 201 Created

curl -X POST http://localhost:12002/api/v1/workflows/<workflowId>/execute \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"payload":{"test":"data"}}'
# 201 — execution started

Payment webhooks

# Stripe CLI simulates a real event end to end
stripe listen --forward-to localhost:12002/api/v1/webhooks/stripe
stripe trigger checkout.session.completed