Skip to content
Kesita Kesita Kesita docs

Testing

Use the smallest check that proves the change.

Terminal window
pnpm --filter kesita-app test
pnpm --filter kesita-app typecheck
pnpm --filter kesita-app lint
pnpm go:test
pnpm go:vet

Integration tests

Section titled “Integration tests”

Hermit creates an isolated Compose project, databases, network, fixtures, and evidence for every suite. It never reuses the normal kesita dev database and never calls paid providers.

Terminal window
./bin/hermit validate-plan tests/plans/platform/integration.yaml
./bin/hermit run tests/plans/platform/integration.yaml
flowchart LR
    Plan[Test plan] --> Validate[Validate suites]
    Validate --> Stack[Create isolated stack]
    Stack --> Fixtures[Load synthetic fixtures]
    Fixtures --> Test[Run tests]
    Test --> Evidence[Collect logs and results]
    Evidence --> Cleanup[Remove containers and volumes]

Plans live in tests/plans/, suites in tests/suites/, and synthetic data in tests/fixtures/. The suite catalog at tools/hermit/catalog.yaml defines available dependencies and scenarios.

Results are written below artifacts/hermit/. Check both test execution and cleanup before treating a run as successful. Failed artifacts may contain operational detail, so do not publish them as documentation.

Add a suite

Section titled “Add a suite”
  1. Copy the closest existing suite and keep its command, dependencies, timeout, and fixture contract together.
  2. Use only synthetic, deterministic fixtures.
  3. Validate and run the suite locally.
  4. Add it to the relevant plan and CI selection; a YAML file alone is not a gate.
flowchart LR
    TestCode[Test implementation] --> Suite[Suite definition]
    Suite --> Plan[Plan selection]
    Plan --> CI[CI execution]

Unit tests do not prove row-level security, database roles, service authentication, or recovery behavior. Use the integration plan for those boundaries. Browser suites select the Playwright runner in their Hermit definition; browsers and dependencies are installed in the runner image before its offline test phase.

Worker coordination has a dedicated cold PostgreSQL suite: ./bin/hermit test tests/suites/data-foundation/worker-coordination.yaml. It uses real worker subprocesses, including SIGKILL and SIGSTOP/SIGCONT, rather than mocking lease expiry alone. See worker recovery for the architecture, timing budgets, fencing guarantees, and failure cases. The suite is included in both the AIX and platform integration plans.

Its go-workflows runner builds only the shared Go runtime tests and uses a PostgreSQL client image. It does not require the web app, Node dependencies, or unrelated service test binaries. All seven coordination test groups are required: recovery contracts, process recovery, private watchdogs, business-queue stalls, renewal timing, extended queue/child/cleanup contracts, and poison-workflow quarantine. The binary has a 10-minute timeout and the suite 12 minutes; a skipped fixture or missing test is a failure. Product lifecycle and corpus-worker suites separately verify terminal business-state reconciliation after recovery exhaustion.