Skip to main content

Test Cases

Planned

Structured test case tracking is planned. Today, the source of truth is the package test scripts, GitHub Actions workflows, Vitest configs, contracts test scripts, Playwright config, and test-quality guardrail. Use this page as an orientation map, not as proof that every listed workflow has full automated coverage.

Current source-backed test surfaces​

SurfaceCurrent source-backed state
Root unit/integration loopbun run test fans out to shared, client, admin, indexer, contracts, and agent package test scripts.
Package CI workflowscontracts.yml, indexer.yml, shared.yml, client.yml, admin.yml, and agent.yml own package tests/builds with dependency fanout for shared, root dependency/config, and relevant contract artifact changes.
Playwright E2EClient and admin browser gates are folded into client.yml and admin.yml via the focused client-ci and admin-ci Playwright projects. Broader/mobile/fork projects stay manual.
Contract fork testscontracts.yml has a fork-readiness job that requires RPC secrets and only runs on trusted pushes or manual dispatch. It is not part of the default local bun run test loop.
Coverage thresholdsCoverage is V8-based where configured, but thresholds differ by package: client is higher than 70%, admin/shared use 70%, and agent intentionally uses lower thresholds.
Test-quality guardrailbash scripts/quality/check-test-quality.sh checks test-quality patterns across test directories.

Planned catalog scope​

The future structured catalog should map test cases to source-backed scripts, workflows, or acceptance artifacts before it presents them as enforced coverage. Candidate categories are:

  • Work submission flows -- gardener creates work, uploads media to IPFS, submits EAS attestation, resolver validates
  • Garden lifecycle -- minting, module initialization, role assignment, metadata updates, action publishing
  • Attestation validation -- resolver role checks, action validity, struct-vs-tuple encoding correctness
  • Offline sync -- draft creation in IndexedDB, job queue processing, conflict resolution on reconnect
  • Wallet and passkey auth -- wallet connect, passkey registration, session management, smart account creation
  • Hypercert minting -- metadata assembly, allowlist generation, minting, marketplace listing
  • Vault operations -- deposits, yield harvesting, three-way splitting, withdrawal

Test Cases​

Planned catalog

Test cases are not yet maintained as a canonical checked-in test-case repository. Add links to concrete tests, workflows, or acceptance artifacts before treating a category as covered.

Critical Path: Work Submission to Attestation​

The core user journey that must never break:

  1. Gardener selects an action and fills out work form
  2. Media files are uploaded to IPFS through the Pinata-backed upload path
  3. Metadata JSON is uploaded to IPFS
  4. Work attestation is encoded and submitted to EAS
  5. WorkResolver validates: gardener role, action validity, data format
  6. Attestation is stored on-chain
  7. Operator reviews and submits WorkApproval attestation
  8. WorkApprovalResolver validates: operator role, work reference, confidence/method

Offline Sync​

  • Draft creation persists to IndexedDB when offline
  • Job queue processes pending jobs when connectivity returns
  • Background sync (service worker) flushes queue on BACKGROUND_SYNC event
  • Retry policy: exponential backoff (1s base, doubling, max 60s, 5 retries)
  • Mutex prevents concurrent flush operations
  • Conflict resolution: last-write-wins for draft updates

Authentication​

  • Wallet connect: MetaMask, WalletConnect, Coinbase Wallet
  • Passkey registration: WebAuthn credential creation, smart account deployment
  • Session management: auth state machine transitions (disconnected, connecting, connected, authenticated)
  • Role verification: hat-based role checks for gardener, operator, evaluator actions

Garden Management​

  • Garden minting triggers module fan-out (Hats tree, vaults, cookie jars, ENS, communities)
  • Role assignment via Hats Protocol (6-role tree per garden)
  • Action publishing with domain categorization and metadata
  • Garden metadata updates via tokenbound account

Impact Pipeline​

  • Assessment creation with strategy kernel (diagnosis, SMART outcomes, Cynefin phase)
  • Hypercert minting from approved work (metadata, allowlist, distribution)
  • Marketplace listing and trading (LooksRare protocol integration)
  • Conviction voting on registered hypercerts via Gardens V2 signal pools

Automation boundaries​

CI pipeline​

  • GitHub Actions are split into eight lanes: contracts, indexer, shared, client, admin, agent, design, and docs.
  • Playwright E2E is package-scoped in CI: client-ci runs client smoke and critical client specs; admin-ci runs admin smoke and production-flow specs.
  • Contract tests run through package scripts; fork readiness needs RPC secrets and runs only on trusted pushes or manual dispatch.

Pre-commit​

  • Pre-commit runs lint-staged, which currently formats staged JS/TS/JSON files and excludes generated/out contract paths.
  • Pre-push runs broader repo checks, including format:contracts, format, and lint.
  • Treat hooks as formatting and lint guardrails, not as proof that tests, typecheck, or full quality gates have run.

E2E (Playwright)​

  • Curated CI projects cover client smoke plus critical client flows, and admin smoke plus production flows.
  • Manual projects can run broader browser/mobile coverage when needed.
  • Fork-backed browser coverage is a separate path from the default CI E2E project set.

Coverage​

  • Coverage thresholds are package-specific, not one universal 70% rule.
  • Client, admin, shared, and agent use V8 coverage configs; indexer coverage is informational in CI.
  • Treat coverage as one signal alongside realism checks, E2E coverage, and human review.

Status​

Current test infrastructure is operational, but the structured catalog is still planned. Known gaps:

  • This page is not yet generated from or linked to a canonical test-case source.
  • Planned categories need explicit links to current tests before they can be described as covered.
  • E2E and fork coverage remain curated and environment-dependent.
  • Load testing and broad cross-chain verification should not be implied unless a checked-in workflow or script proves them.