testing

23 modules

• testing/admin_integration.ts

  Standard admin integration test suite for fuz_app admin routes.

  describe_standard_admin_integration_tests creates a composable test suite that exercises admin account listing, permit grant/revoke, session/token management, and audit log routes against a real PGlite database.

  Consumers call it with their route factory, session config, and role schema — all admin route tests come for free.

• testing/adversarial_404.ts

  Adversarial 404 testing for routes with params and declared 404 error schemas.

  Creates stub handlers that return 404 with the declared error code, fires requests with valid-format-but-nonexistent params (nil UUIDs), and validates response bodies against the declared 404 Zod schemas.

  No DB needed — tests schema conformance of 404 responses, not real handlers.

• testing/adversarial_headers.ts

  Adversarial header attack test suite.

  Provides standard header injection test cases and a convenience wrapper for exercising middleware stacks with adversarial headers.

• testing/adversarial_input.ts

  Adversarial input validation testing for route specs.

  Walks Zod schemas directly to generate payloads that must fail validation. Fires requests against a test app and asserts 400 responses before handlers are reached.

  Tests are focused: one representative wrong-type value per field, one format violation per constrained field, one null and one missing test per required field, plus whole-body structural attacks (non-object body, extra unknown keys).

• testing/app_server.ts

  Bootstrapped app server factory for integration tests.

  Creates a keeper account, API token, and signed session cookie on a database. By default uses a cached in-memory PGlite (shared WASM instance per vitest worker thread via test_db.ts module cache); pass db to use an existing database (any driver) instead.

  Also provides create_test_app — a combined helper that creates both a TestAppServer and a fully assembled Hono app with middleware and routes.

• testing/assert_dev_env.ts

• testing/assertions.ts

  Assertion helpers for auth attack surface testing.

  Plain functions called inside explicit test() blocks to verify surface snapshots, public routes, and middleware stacks.

• testing/attack_surface.ts

  Adversarial auth enforcement test runners and the standard attack surface suite.

  The combinatorial test runner (describe_adversarial_auth) generates test suites for routes x auth levels. The standard suite (describe_standard_attack_surface_tests) composes all attack surface test groups into a single call.

  Stubs, app factories, and assertion helpers live in focused submodules: - test_auth_stubs — stub factories and pre-built dep bundles - test_auth_apps — auth-level test app factories - test_auth_assertions — snapshot, public route, and middleware assertions

• testing/audit_completeness.ts

  Composable audit log completeness test suite.

  Verifies that every auth mutation route produces the expected audit log event. Uses the real middleware stack and database — audit events are verified by querying the audit_log table after each request.

  Bootstrap is excluded because it requires filesystem token state that create_test_app does not provide. Bootstrap audit logging is tested separately in bootstrap_account.db.test.ts.

• testing/auth_apps.ts

  Auth test app factories for adversarial testing.

  Creates Hono test apps at each auth level (public, authenticated, keeper, per-role) for use in adversarial auth enforcement and input validation tests.

• testing/data_exposure.ts

  Composable data exposure test suite.

  Verifies that sensitive database fields never leak through HTTP responses: - Schema-level: walks JSON Schema output/error schemas for blocklisted property names - Runtime: fires real requests and checks response bodies against field blocklists - Cross-privilege: verifies admin routes return 403 for non-admin users, and non-admin responses exclude admin-only fields

• testing/db.ts

  Test database fixtures for parameterized testing.

  Provides factory builders for creating test databases with pglite (in-memory) and pg (PostgreSQL) drivers. Consumer projects provide their own schema initialization via run_migrations and compose factories into test suites.

  @example

  import {create_pglite_factory, create_pg_factory} from '@fuzdev/fuz_app/testing/db.js'; import {run_migrations} from '@fuzdev/fuz_app/db/migrate.js'; import {AUTH_MIGRATION_NS} from '@fuzdev/fuz_app/auth/migrations.js'; const init_schema = async (db) => { await run_migrations(db, [AUTH_MIGRATION_NS]); }; const pglite_factory = create_pglite_factory(init_schema); const pg_factory = create_pg_factory(init_schema, process.env.TEST_DATABASE_URL); export const db_factories = [pglite_factory, pg_factory];

• testing/entities.ts

  Shared test entity factories for Account, Actor, Permit, and RequestContext.

  Accepts Partial<T> overrides — callers set only what matters to their test. Uses create_test_* names to avoid collisions with real create_account_with_actor from account_queries.ts.

• testing/error_coverage.ts

  Error reachability coverage tracking.

  Tracks which declared error statuses are actually exercised in tests. ErrorCoverageCollector records status codes observed during test runs, then assert_error_coverage compares against declared error schemas to find uncovered error paths.

• testing/integration_helpers.ts

  Integration test helpers — route lookup, response validation, and cookie utilities.

• testing/integration.ts

  Standard integration test suite for fuz_app auth routes.

  describe_standard_integration_tests creates a composable test suite that exercises the full middleware stack (origin, session, bearer_auth, request_context) against a real PGlite database. Consumers call it with their route factory and session config — all auth route tests come for free.

  Tests use stub_password_deps (deterministic hashing, no Argon2 overhead). Login handlers call verify_password(submitted, stored_hash) which works because both hash and verify use the same stub logic.

  Rate limiters are disabled by default — tests make many login attempts and would trigger limits otherwise.

• testing/middleware.ts

  Table-driven middleware test helpers.

  Provides mock builders for bearer auth middleware dependencies, a generic test runner that iterates case tables, and a reusable middleware stack factory for integration testing.

• testing/rate_limiting.ts

  Rate limiting integration test suite.

  Verifies that sensitive routes (login, bootstrap, token creation) enforce rate limits when rate limiters are enabled. Tests create a tight rate limiter (2 attempts / 1 minute) and fire requests until 429 is returned.

  Consumers call describe_rate_limiting_tests with their route factory and session config — rate limit enforcement tests come for free.

• testing/round_trip.ts

  Schema-driven round-trip validation test suite.

  For every route spec, generates a valid request (auth, params, body) and validates the response against declared output or error schemas. DB-backed via create_test_app — exercises the full middleware stack.

• testing/schema_generators.ts

  Schema-driven value generation helpers for testing.

  Walks Zod schemas to generate valid values for route params, request bodies, and URL paths. Used by adversarial input, adversarial 404, and round-trip validation test suites.

• testing/standard.ts

  Combined standard test suite helper.

  Convenience wrapper that runs both describe_standard_integration_tests and describe_standard_admin_integration_tests in a single call. Existing per-suite calls keep working — this is purely additive.

• testing/stubs.ts

  Stub factories for auth surface testing.

  Provides throwing stubs (catch unexpected access), no-op stubs (allow access without side effects), and pre-built bundles for AppDeps.

• testing/surface_invariants.ts

  Surface invariant assertions for AppSurface data.

  Two categories: - Structural — validate internal consistency (error schema presence, descriptions, duplicates, middleware propagation, error schema validity, error code consistency). No options needed. - Policy — enforce security policy (sensitive routes rate-limited, no public mutations, mutation method conventions). Configurable with sensible defaults.

  Structural invariants catch schema/surface generation bugs. Policy invariants catch security misconfigurations. Both propagate automatically to consumers via assert_surface_invariants.