go-testing-quality

Define a slice of anonymous structs holding inputs and expected outputs, loop over it, and run each case with t.Run(tc.name, ...) for isolation. Name every case so you can target it with go test -run TestName/casename, and use t.Fatalf for precondition failures and t.Errorf for independent field checks.

assert records a failure and continues the test, returning a bool for guarding further checks. require records a failure and aborts the test via t.FailNow. Use require for preconditions like unexpected errors and assert for the actual independent expectations.

Write a function like func FuzzXxx(f *testing.F), seed the corpus with f.Add, and assert invariants inside f.Fuzz. Run it with go test -run=Fuzz -fuzz=FuzzXxx -fuzztime=30s; crashers are saved to testdata/fuzz and replayed as regression cases.

No. A clean go test -race run only reports races actually exercised during execution, so it is not a proof of absence. Pair it with t.Parallel() and realistic concurrency in tests, and run it in CI on every pull request.

Use Profile-Guided Optimization after benchmarks and pprof profiles confirm real hotspots in production. Save a representative CPU profile as default.pgo in the main package directory and go build picks it up automatically, typically yielding single-digit percent gains.

Do not use it for CI pipeline wiring, golangci-lint or govulncheck setup, which belong to tooling and security skills. It also does not cover project architecture, SOLID enforcement, or non-Go test suites like Pest, Vitest, Jest, or cargo test.