golang-testinglisted

# Go Testing Keep the smallest set of tests that protects important observable behavior and produces useful failures. Match the repository's existing testing style and dependencies; a change does not automatically require a new test or test file. ## Start from the Contract 1. Read the implementation, callers, public documentation, existing tests, and nearby helpers. 2. Identify inputs, outputs, side effects, error identity, ordering, timing, concurrency, and ownership that callers can observe. 3. Inspect existing coverage and choose the smallest test level that exercises the contract reliably. 4. For an important uncovered regression, extend an existing test or add a focused failing case before changing production code when practical. 5. Avoid asserting incidental implementation details unless they are the contract under review. ## Decide What Earns a Test Before adding a case, identify the observable failure it would catch and why existing checks would miss it. A local rename, formatting change, incidental output wording, or mechanical move usually needs existing checks rather than new assertions. Add coverage when important behavior affected by the work remains unprotected, including behavior a refactor must preserve; do not optimize for test count or coverage percentage. When reviewing or simplifying a suite: - Keep distinct contracts such as data integrity, authorization, persistence, error recovery, and resource ownership covered at a useful boundary. - Prefer one