What problem does it solve? Writing usecase tests in Go often leads to bloated suites that re-verify domain rules, SQL correctness, or handler concerns, or to mock-heavy interaction tests that only count calls. This Skill defines exactly what a usecase test should verify: the five wiring viewpoints (input resolution, multi-aggregate coordination, source selection, transaction boundaries, command dispatch and persistence), checked against real infrastructure. ## Core Features & Use Cases - Five-viewpoint case design: Classifies each line of a usecase's Execute method into input resolution, aggregate coordination, source selection, transaction boundary, or command dispatch, and writes one test case per distinct wiring branch. - Real infrastructure testing: Runs tests against a dockertest PostgreSQL instance with real repositories, real tx.Manager, and real query services, replacing only the IDGenerator with a deterministic fixed implementation. - Table-driven structure: Enforces a seed{Table} → ids → in → want/wantErr/want{Table} field order with rdbtest helpers for seeding and reading rows, keeping raw SQL and aggregate assembly out of test bodies. - Use Case: Given a ConfirmReservation usecase, produce four test cases covering empty-ID rejection, successful confirmation with event persistence, idempotent re-confirmation rejection, and rollback on mid-save constraint failure. ## Quick Start Ask the AI to write tests for this usecase following the test-usecase convention, pointing it at the usecase implementation and the rdbtest persistence test helpers.
