golang-testinglisted

# Go Testing Write tests that constrain observable behavior and produce useful failures. Match the repository's existing testing style and dependencies before introducing a new framework or generator. ## 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. Choose the smallest test level that exercises the contract reliably. 4. Reproduce a bug with a failing test before changing production code when practical. 5. Avoid asserting incidental implementation details unless they are the contract under review. ## Choose a Test Shape - Use a direct test for one behavior with a short setup. - Use table-driven subtests when cases share the same arrange/act/assert structure and case names make failures clearer. Do not force unrelated scenarios into a large table. - Use examples when executable documentation and rendered output are the primary value. - Use fuzzing for parsers, codecs, state transitions, and input spaces with useful invariants. Seed important regressions. - Use integration tests when the contract depends on a real database, filesystem, network protocol, process, or service behavior that a unit test cannot establish. - Use benchmarks only for performance questions; functional tests should not encode fragile timing budgets. Read [table, fuzz, and example recipes](reference