← ClaudeAtlas

go-test-strategylisted

Falsification design. Use while writing tests when a failure observable, deterministic control, or proving layer is non-obvious; resolve that choice inside the current implementation task.
Dankosik/go-service-template-rest · ★ 7 · API & Backend · score 78
Install: claude install-skill Dankosik/go-service-template-rest
# Go Test Strategy Choose a test that rejects plausible wrong behavior at the smallest layer that can observe it. This is an optional method while implementing code or tests, not a separate phase, approval, or mandatory preliminary test plan. Ground the assertion in accepted product behavior, not the implementation's current output. Reuse existing test patterns and controls. Preserve fixture cardinality, entity ownership, absent values, and event ordering. Prefer assertions that survive behavior-preserving refactors; test internal calls only when they carry an accepted contract or resource bound. For the concrete choice in front of you, identify the wrong behavior, its observable consequence, and deterministic inputs or fault control. Unit tests are sufficient when they observe that consequence. Exercise available real in-process boundaries where a mock would miss the wrong behavior. An explicit real-database or provider verification claim needs that actual boundary, but this method cannot make such a claim mandatory for local completion. Follow the [Evidence Contract](../../../docs/spec-first-workflow/shared/evidence-contract.md#required-and-optional-proof) before selecting external infrastructure. Do not build a test environment, runner, or scenario matrix merely because a mock has limits. Small fixtures and existing test doubles remain normal test authoring; keep optional unobserved scope clear. Load one [decision reference](references/decision/index.md) only when its