Write Vibe Tests

Use this skill to make Vibe architecture testable, not just well-shaped. Tests should protect observable behavior while allowing internals to move.

Core Principle

Test behavior through stable boundaries. Do not couple tests to private methods, internal call choreography, or temporary structure.

If a refactor changes no observable behavior but breaks many tests, the tests are probably coupled to implementation details.

Vibe Test Boundaries

Code area	Preferred test boundary
Core use cases and services	Public function/class API, typed events, model outputs, persisted state
Tools	Owning app-server capability contract, typed invocation/results, permissions and user-facing errors; BaseTool.invoke/run for retained BaseTool implementations
LLM/backend orchestration	Native Unified Runtime through serialized app-server RPCs, with deterministic fake completion/discovery services
Config	Pydantic model validation, layer merge outputs, migration results
Sessions	Runtime session operations, durability/recovery and app-server projections; JSONL/metadata only for the supported read-only historical importer
Terminal UI (vibe/cli-rust)	Rust unit tests for pure logic, client-e2e scenarios and goldens for rendering and interaction (see vibe/cli-rust/AGENTS.md)
ACP	ACP session updates and protocol-facing content, not core internals

Prefer Fakes Over Mocks

Prefer in-memory implementations and fake adapters that implement real contracts.

• Put reusable test doubles in tests/stubs/ and name them Fake*.
• Make fakes small and behavior-oriented.
• Mock only at hard process, network, time, or third-party boundaries when a fake would be more complex than the behavior under test.
• Avoid assertions like "method X was called with Y" unless the call itself is the observable contract.

Legacy Or Refactor Workflow

When code is hard to test: