HoBo
Design
Examples Search docs

Testing overview

Trust the bindle, test the journey — without a cloud account until you want one.

HoBo collapses a lot of “special testing tools” into one idea: every boundary is typed and contract-backed, so you can point it at a different mode (live, mock, replay, bridge, shadow, fault) without rewriting the app. The patterns below are deliberate product features, not ad-hoc test helpers.

Mental model

IdeaWhat it buys you
Contracts bound shapeConsumer-driven expectations; providers can grow without breaking consumers
Boundary modesSame production code path, different routing (mock / live / replay / bridge / shadow / fault)
EffectSpecPure work isolates with zero infra; domain I/O drives automatic mocks
ResilienceProfileFault-injection guided by the contract; never retries policy denials or terminal failures
Event logReplay-equals-live; inspection without re-running side effects
SQLite journalReal durability semantics offline (CAS, fencing, atomic effects)

Layers (read in this order)

  1. Unit tests & boundaries — unit tests; boundaries auto-mock from contract examples.
  2. Aggregates & CQRS — pure decide, fenceToken, conflict vs invariant.
  3. Contracts & PACT — consumer/provider executable contracts; subset matching.
  4. Effect-aware isolation — pure vs domain-effect harness modes.
  5. Dual fixtures — pure path vs effect path from the same metadata.
  6. Durable EventStore — stream-head CAS, fencing, positions, restart.
  7. Migration fixtures — legacy schema → current, fail-closed integrity.
  8. Queue, timer, outbox — lease fences, once-after-restart timers.
  9. Deployment rehearsal — hobo plan, local lane, Gatekeeper.
  10. Bridge modes — live/mock/bridge/replay/shadow/fault.
  11. Chaos & availability — session faults, synthetics, shadow.
  12. Property & model — journal ≡ reference model.
  13. Behavior & Cucumber — Gherkin evidence, not live E2E.
  14. Benchmarks — catch algorithmic regressions.
  15. Conformance & golden — port suites + deploy golden gate.
  16. Anti-patterns — what not to do.

What you should not do

  • Hand-write long-lived mocks that drift from contracts — use contract examples / effect harness mocks.
  • Treat COUNT(*) stream length or multi-writer shared SQLite as “the real” store — the product uses stream heads and single-owner partitions.
  • Retry policy.Decided denials or terminal WIT failures in tests “to be resilient” — that is a bug in the product model.
  • Run broad full-repo test sweeps to discover code — search first, then narrow package tests.