[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NCJRFXQ8FSDEV3C714Z52":3,"skill-same:01M71NCJRFXQ8FSDEV3C714Z52":113},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":71,"commitSha":72,"skillDirectory":73,"forksCount":14,"repositoryHtmlUrl":74,"repositoryHomepageUrl":75,"ownerHtmlUrl":76,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":77,"install":78,"resources":90},"01M71NCJRFXQ8FSDEV3C714Z52","golang-testing",null,"Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky\u002Fslow tests. For testify-specific APIs see `samber\u002Fcc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber\u002Fcc-skills-golang@golang-benchmark`.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"testing","golang","golang testing","snapshot","benchmark","edit","write","read","code","Bash","when","debugging","writing","production-ready","ci","up","projects","ready","ai coding agents","coverage","2026-11-10 10:56:23",false,"---\nname: golang-testing\ndescription: \"Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky\u002Fslow tests. For testify-specific APIs see `samber\u002Fcc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber\u002Fcc-skills-golang@golang-benchmark`.\"\nuser-invocable: true\nlicense: MIT\ncompatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.\nmetadata:\n  author: samber\n  version: \"1.2.3\"\n  openclaw:\n    emoji: \"🧪\"\n    homepage: https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang\n    requires:\n      bins:\n        - go\n        - gotests\n    install:\n      - kind: go\n        package: github.com\u002Fcweill\u002Fgotests\u002Fgotests@latest\n        bins: [gotests]\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(gotests:*) AskUserQuestion\n---\n\n**Persona:** You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior, not to hit coverage targets.\n\n**Thinking mode:** Use `ultrathink` for test strategy design and failure analysis. Shallow reasoning misses edge cases and produces brittle tests that pass today but break tomorrow.\n\n**Orchestration mode:** Use `ultracode` for auditing a large test suite — orchestrate the three sub-agents described in Audit mode (unit quality and coverage gaps, integration isolation, goroutine\u002Frace issues) and merge their findings into one gap report.\n\n**Modes:**\n\n- **Write mode** — generating new tests for existing or new code. Work sequentially through the code under test; use `gotests` to scaffold table-driven tests, then enrich with edge cases and error paths.\n- **Review mode** — reviewing a PR's test changes. Focus on the diff: check coverage of new behaviour, assertion quality, table-driven structure, and absence of flakiness patterns. Sequential.\n- **Audit mode** — auditing an existing test suite for gaps, flakiness, or bad patterns (order-dependent tests, missing `t.Parallel()`, implementation-detail coupling). Launch up to 3 parallel sub-agents split by concern: (1) unit test quality and coverage gaps, (2) integration test isolation and build tags, (3) goroutine leaks and race conditions.\n- **Debug mode** — a test is failing or flaky. Work sequentially: reproduce reliably, isolate the failing assertion, trace the root cause in production code or test setup.\n\n> **Community default.** A company skill that explicitly supersedes `samber\u002Fcc-skills-golang@golang-testing` skill takes precedence.\n\n**Dependencies:**\n\n- gotests: `go install github.com\u002Fcweill\u002Fgotests\u002Fgotests@latest`\n\n# Go Testing Best Practices\n\nThis skill guides the creation of production-ready tests for Go applications. Follow these principles to write maintainable, fast, and reliable tests.\n\n## Best Practices Summary\n\n1. Table-driven tests MUST use named subtests -- every test case needs a `name` field passed to `t.Run`\n2. Integration tests MUST use build tags (`\u002F\u002Fgo:build integration`) to separate from unit tests\n3. Tests MUST NOT depend on execution order -- each test MUST be independently runnable\n4. Independent tests SHOULD use `t.Parallel()` when possible\n5. NEVER test implementation details -- test observable behavior and public API contracts\n6. Packages with goroutines SHOULD use `goleak.VerifyTestMain` in `TestMain` to detect goroutine leaks\n7. Use testify as helpers, not a replacement for standard library\n8. Mock interfaces, not concrete types\n9. Keep unit tests fast (\u003C 1ms), use build tags for integration tests\n10. Run tests with race detection in CI\n11. Include examples as executable documentation\n\n## Test Structure and Organization\n\n### File Conventions\n\n```go\n\u002F\u002F package_test.go - tests in same package (white-box, access unexported)\npackage mypackage\n\n\u002F\u002F mypackage_test.go - tests in test package (black-box, public API only)\npackage mypackage_test\n```\n\n### Naming Conventions\n\n```go\nfunc TestAdd(t *testing.T) { ... }               \u002F\u002F function test\nfunc TestMyStruct_MyMethod(t *testing.T) { ... } \u002F\u002F method test\nfunc BenchmarkAdd(b *testing.B) { ... }          \u002F\u002F benchmark\nfunc ExampleAdd() { ... }                        \u002F\u002F example\nfunc FuzzAdd(f *testing.F) { ... }               \u002F\u002F fuzz test\n```\n\n## Table-Driven Tests\n\nTable-driven tests are the idiomatic Go way to test multiple scenarios. Always name each test case.\n\n```go\nfunc TestCalculatePrice(t *testing.T) {\n    tests := []struct {\n        name     string\n        quantity int\n        unitPrice float64\n        expected  float64\n    }{\n        {\n            name:      \"single item\",\n            quantity:  1,\n            unitPrice: 10.0,\n            expected:  10.0,\n        },\n        {\n            name:      \"bulk discount - 100 items\",\n            quantity:  100,\n            unitPrice: 10.0,\n            expected:  900.0, \u002F\u002F 10% discount\n        },\n        {\n            name:      \"zero quantity\",\n            quantity:  0,\n            unitPrice: 10.0,\n            expected:  0.0,\n        },\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            got := CalculatePrice(tt.quantity, tt.unitPrice)\n            if got != tt.expected {\n                t.Errorf(\"CalculatePrice(%d, %.2f) = %.2f, want %.2f\",\n                    tt.quantity, tt.unitPrice, got, tt.expected)\n            }\n        })\n    }\n}\n```\n\n## Unit Tests\n\nUnit tests should be fast (\u003C 1ms), isolated (no external dependencies), and deterministic.\n\n## Testing HTTP Handlers\n\nUse `httptest` for handler tests with table-driven patterns. See [HTTP Testing](.\u002Freferences\u002Fhttp-testing.md) for examples with request\u002Fresponse bodies, query parameters, headers, and status code assertions.\n\n## Goroutine Leak Detection with goleak\n\nUse `go.uber.org\u002Fgoleak` to detect leaking goroutines, especially for concurrent code:\n\n```go\nimport (\n    \"testing\"\n    \"go.uber.org\u002Fgoleak\"\n)\n\nfunc TestMain(m *testing.M) {\n    goleak.VerifyTestMain(m)\n}\n```\n\nTo exclude specific goroutine stacks (for known leaks or library goroutines):\n\n```go\nfunc TestMain(m *testing.M) {\n    goleak.VerifyTestMain(m,\n        goleak.IgnoreCurrent(),\n    )\n}\n```\n\nOr per-test:\n\n```go\nfunc TestWorkerPool(t *testing.T) {\n    defer goleak.VerifyNone(t)\n    \u002F\u002F ... test code ...\n}\n```\n\n## testing\u002Fsynctest for Deterministic Goroutine Testing\n\n`testing\u002Fsynctest` (Go 1.25+) provides deterministic tests for goroutines, timers, deadlines, and context cancellation. Time advances only when all goroutines are blocked, making ordering predictable.\n\nWhen to use `synctest` instead of real time:\n\n- Testing concurrent code with time-based operations (time.Sleep, time.After, time.Ticker)\n- When race conditions need to be reproducible\n- When tests are flaky due to timing issues\n\n```go\nimport (\n    \"context\"\n    \"testing\"\n    \"testing\u002Fsynctest\"\n    \"time\"\n)\n\nfunc TestContextTimeout(t *testing.T) {\n    synctest.Test(t, func(t *testing.T) {\n        const timeout = 5 * time.Second\n\n        ctx, cancel := context.WithTimeout(t.Context(), timeout)\n        defer cancel()\n\n        time.Sleep(timeout - time.Nanosecond)\n        synctest.Wait()\n        if err := ctx.Err(); err != nil {\n            t.Fatalf(\"before timeout: %v\", err)\n        }\n\n        time.Sleep(time.Nanosecond)\n        synctest.Wait()\n        if err := ctx.Err(); err != context.DeadlineExceeded {\n            t.Fatalf(\"after timeout: got %v, want DeadlineExceeded\", err)\n        }\n    })\n}\n```\n\nUse `synctest.Test` in Go 1.25+ and Go 1.26+. Do not use the old Go 1.24 experimental `synctest.Run` API in Go 1.25+ or Go 1.26+ code. If a module explicitly targets Go 1.24 and opts into `GOEXPERIMENT=synctest`, use the old API only as a compatibility fallback.\n\nKey differences in `synctest`:\n\n- `time.Sleep` advances synthetic time instantly when the goroutine blocks\n- `time.After` fires when synthetic time reaches the duration\n- All goroutines run to blocking points before time advances\n- Test execution is deterministic and repeatable\n\n## Test Timeouts\n\nFor tests that may hang, use a timeout helper that panics with caller location. See [Helpers](.\u002Freferences\u002Fhelpers.md).\n\n## Benchmarks\n\n→ See `samber\u002Fcc-skills-golang@golang-benchmark` skill for advanced benchmarking: `b.Loop()` (Go 1.24+), `benchstat`, profiling from benchmarks, and CI regression detection.\n\nWrite benchmarks to measure performance and detect regressions:\n\n```go\nfunc BenchmarkStringConcatenation(b *testing.B) {\n    b.Run(\"plus-operator\", func(b *testing.B) {\n        for b.Loop() {\n            result := \"a\" + \"b\" + \"c\"\n            _ = result\n        }\n    })\n\n    b.Run(\"strings.Builder\", func(b *testing.B) {\n        for b.Loop() {\n            var builder strings.Builder\n            builder.WriteString(\"a\")\n            builder.WriteString(\"b\")\n            builder.WriteString(\"c\")\n            _ = builder.String()\n        }\n    })\n}\n```\n\nBenchmarks with different input sizes:\n\n```go\nfunc BenchmarkFibonacci(b *testing.B) {\n    sizes := []int{10, 20, 30}\n    for _, size := range sizes {\n        b.Run(fmt.Sprintf(\"n=%d\", size), func(b *testing.B) {\n            b.ReportAllocs()\n            for b.Loop() {\n                Fibonacci(size)\n            }\n        })\n    }\n}\n```\n\nFor Go 1.24+, new benchmarks should use `b.Loop()`. Use legacy `b.N` loops only when the module targets Go \u003C1.24 or when preserving old benchmark code intentionally.\n\n### Go 1.26+: test artifacts\n\nWhen a test, benchmark, or fuzz target needs to persist files for inspection, use `ArtifactDir()` instead of ad-hoc paths or repo-local output.\n\n```go\nfunc TestRenderGoldenArtifact(t *testing.T) {\n    dir := t.ArtifactDir()\n\n    out := filepath.Join(dir, \"rendered.json\")\n    if err := os.WriteFile(out, renderedBytes, 0o644); err != nil {\n        t.Fatal(err)\n    }\n\n    t.Logf(\"artifact written: %s\", out)\n}\n```\n\nAvailable on `*testing.T`, `*testing.B`, and `*testing.F` in Go 1.26+.\n\n## Parallel Tests\n\nUse `t.Parallel()` to run tests concurrently:\n\n```go\nfunc TestParallelOperations(t *testing.T) {\n    tests := []struct {\n        name string\n        data []byte\n    }{\n        {\"small data\", make([]byte, 1024)},\n        {\"medium data\", make([]byte, 1024*1024)},\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            t.Parallel()\n            is := assert.New(t)\n\n            result := Process(tt.data)\n            is.NotNil(result)\n        })\n    }\n}\n```\n\n## Fuzzing\n\nUse fuzzing to find edge cases and bugs:\n\n```go\nfunc FuzzReverse(f *testing.F) {\n    f.Add(\"hello\")\n    f.Add(\"\")\n    f.Add(\"a\")\n\n    f.Fuzz(func(t *testing.T, input string) {\n        reversed := Reverse(input)\n        doubleReversed := Reverse(reversed)\n        if input != doubleReversed {\n            t.Errorf(\"Reverse(Reverse(%q)) = %q, want %q\", input, doubleReversed, input)\n        }\n    })\n}\n```\n\n## Examples as Documentation\n\nExamples are executable documentation verified by `go test`:\n\n```go\nfunc ExampleCalculatePrice() {\n    price := CalculatePrice(100, 10.0)\n    fmt.Printf(\"Price: %.2f\\n\", price)\n    \u002F\u002F Output: Price: 900.00\n}\n\nfunc ExampleCalculatePrice_singleItem() {\n    price := CalculatePrice(1, 25.50)\n    fmt.Printf(\"Price: %.2f\\n\", price)\n    \u002F\u002F Output: Price: 25.50\n}\n```\n\n## Code Coverage\n\n```bash\n# Generate coverage file\ngo test -coverprofile=coverage.out .\u002F...\n\n# View coverage in HTML\ngo tool cover -html=coverage.out\n\n# Coverage by function\ngo tool cover -func=coverage.out\n\n# Total coverage percentage\ngo tool cover -func=coverage.out | grep total\n```\n\n## Integration Tests\n\nUse build tags to separate integration tests from unit tests:\n\n```go\n\u002F\u002Fgo:build integration\n\npackage mypackage\n\nfunc TestDatabaseIntegration(t *testing.T) {\n    db, err := sql.Open(\"postgres\", os.Getenv(\"DATABASE_URL\"))\n    if err != nil {\n        t.Fatal(err)\n    }\n    defer db.Close()\n\n    \u002F\u002F Test real database operations\n}\n```\n\nRun integration tests separately:\n\n```bash\ngo test -tags=integration .\u002F...\n```\n\nFor Docker Compose fixtures, SQL schemas, and integration test suites, see [Integration Testing](.\u002Freferences\u002Fintegration-testing.md).\n\n## Mocking\n\nMock interfaces, not concrete types. Define interfaces where consumed, then create mock implementations.\n\nFor mock patterns, test fixtures, and time mocking, see [Mocking](.\u002Freferences\u002Fmocking.md).\n\n## Enforce with Linters\n\nMany test best practices are enforced automatically by linters: `thelper`, `paralleltest`, `testifylint`. See the `samber\u002Fcc-skills-golang@golang-lint` skill for configuration and usage.\n\n## Cross-References\n\n- -> See `samber\u002Fcc-skills-golang@golang-stretchr-testify` skill for detailed testify API (assert, require, mock, suite)\n- -> See `samber\u002Fcc-skills-golang@golang-database` skill (testing.md) for database integration test patterns\n- -> See `samber\u002Fcc-skills-golang@golang-concurrency` skill for goroutine leak detection with goleak\n- -> See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for CI test configuration and GitHub Actions workflows\n- -> See `samber\u002Fcc-skills-golang@golang-lint` skill for testifylint and paralleltest configuration\n- -> See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines\n\n## Quick Reference\n\n```bash\ngo test .\u002F...                          # all tests\ngo test -run TestName .\u002F...            # specific test by exact name\ngo test -run TestName\u002Fsubtest .\u002F...    # subtests within a test\ngo test -run 'Test(Add|Sub)' .\u002F...     # multiple tests (regexp OR)\ngo test -run 'Test[A-Z]' .\u002F...         # tests starting with capital letter\ngo test -run 'TestUser.*' .\u002F...        # tests matching prefix\ngo test -run '.*Validation.*' .\u002F...    # tests containing substring\ngo test -run TestName\u002F. .\u002F...          # all subtests of TestName\ngo test -run '\u002F(unit|integration)' .\u002F... # filter by subtest name\ngo test -race .\u002F...                    # race detection\ngo test -cover .\u002F...                   # coverage summary\ngo test -bench=. -benchmem .\u002F...       # benchmarks\ngo test -fuzz=FuzzName .\u002F...           # fuzzing\ngo test -tags=integration .\u002F...        # integration tests\n```\n","**Persona:** You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior, not to hit coverage targets.\n\n**Thinking mode:** Use `ultrathink` for test strategy design and failure analysis. Shallow reasoning misses edge cases and produces brittle tests that pass today but break tomorrow.\n\n**Orchestration mode:** Use `ultracode` for auditing a large test suite — orchestrate the three sub-agents described in Audit mode (unit quality and coverage gaps, integration isolation, goroutine\u002Frace issues) and merge their findings into one gap report.\n\n**Modes:**\n\n- **Write mode** — generating new tests for existing or new code. Work sequentially through the code under test; use `gotests` to scaffold table-driven tests, then enrich with edge cases and error paths.\n- **Review mode** — reviewing a PR's test changes. Focus on the diff: check coverage of new behaviour, assertion quality, table-driven structure, and absence of flakiness patterns. Sequential.\n- **Audit mode** — auditing an existing test suite for gaps, flakiness, or bad patterns (order-dependent tests, missing `t.Parallel()`, implementation-detail coupling). Launch up to 3 parallel sub-agents split by concern: (1) unit test quality and coverage gaps, (2) integration test isolation and build tags, (3) goroutine leaks and race conditions.\n- **Debug mode** — a test is failing or flaky. Work sequentially: reproduce reliably, isolate the failing assertion, trace the root cause in production code or test setup.\n\n> **Community default.** A company skill that explicitly supersedes `samber\u002Fcc-skills-golang@golang-testing` skill takes precedence.\n\n**Dependencies:**\n\n- gotests: `go install github.com\u002Fcweill\u002Fgotests\u002Fgotests@latest`\n\n# Go Testing Best Practices\n\nThis skill guides the creation of production-ready tests for Go applications. Follow these principles to write maintainable, fast, and reliable tests.\n\n## Best Practices Summary\n\n1. Table-driven tests MUST use named subtests -- every test case needs a `name` field passed to `t.Run`\n2. Integration tests MUST use build tags (`\u002F\u002Fgo:build integration`) to separate from unit tests\n3. Tests MUST NOT depend on execution order -- each test MUST be independently runnable\n4. Independent tests SHOULD use `t.Parallel()` when possible\n5. NEVER test implementation details -- test observable behavior and public API contracts\n6. Packages with goroutines SHOULD use `goleak.VerifyTestMain` in `TestMain` to detect goroutine leaks\n7. Use testify as helpers, not a replacement for standard library\n8. Mock interfaces, not concrete types\n9. Keep unit tests fast (\u003C 1ms), use build tags for integration tests\n10. Run tests with race detection in CI\n11. Include examples as executable documentation\n\n## Test Structure and Organization\n\n### File Conventions\n\n```go\n\u002F\u002F package_test.go - tests in same package (white-box, access unexported)\npackage mypackage\n\n\u002F\u002F mypackage_test.go - tests in test package (black-box, public API only)\npackage mypackage_test\n```\n\n### Naming Conventions\n\n```go\nfunc TestAdd(t *testing.T) { ... }               \u002F\u002F function test\nfunc TestMyStruct_MyMethod(t *testing.T) { ... } \u002F\u002F method test\nfunc BenchmarkAdd(b *testing.B) { ... }          \u002F\u002F benchmark\nfunc ExampleAdd() { ... }                        \u002F\u002F example\nfunc FuzzAdd(f *testing.F) { ... }               \u002F\u002F fuzz test\n```\n\n## Table-Driven Tests\n\nTable-driven tests are the idiomatic Go way to test multiple scenarios. Always name each test case.\n\n```go\nfunc TestCalculatePrice(t *testing.T) {\n    tests := []struct {\n        name     string\n        quantity int\n        unitPrice float64\n        expected  float64\n    }{\n        {\n            name:      \"single item\",\n            quantity:  1,\n            unitPrice: 10.0,\n            expected:  10.0,\n        },\n        {\n            name:      \"bulk discount - 100 items\",\n            quantity:  100,\n            unitPrice: 10.0,\n            expected:  900.0, \u002F\u002F 10% discount\n        },\n        {\n            name:      \"zero quantity\",\n            quantity:  0,\n            unitPrice: 10.0,\n            expected:  0.0,\n        },\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            got := CalculatePrice(tt.quantity, tt.unitPrice)\n            if got != tt.expected {\n                t.Errorf(\"CalculatePrice(%d, %.2f) = %.2f, want %.2f\",\n                    tt.quantity, tt.unitPrice, got, tt.expected)\n            }\n        })\n    }\n}\n```\n\n## Unit Tests\n\nUnit tests should be fast (\u003C 1ms), isolated (no external dependencies), and deterministic.\n\n## Testing HTTP Handlers\n\nUse `httptest` for handler tests with table-driven patterns. See [HTTP Testing](.\u002Freferences\u002Fhttp-testing.md) for examples with request\u002Fresponse bodies, query parameters, headers, and status code assertions.\n\n## Goroutine Leak Detection with goleak\n\nUse `go.uber.org\u002Fgoleak` to detect leaking goroutines, especially for concurrent code:\n\n```go\nimport (\n    \"testing\"\n    \"go.uber.org\u002Fgoleak\"\n)\n\nfunc TestMain(m *testing.M) {\n    goleak.VerifyTestMain(m)\n}\n```\n\nTo exclude specific goroutine stacks (for known leaks or library goroutines):\n\n```go\nfunc TestMain(m *testing.M) {\n    goleak.VerifyTestMain(m,\n        goleak.IgnoreCurrent(),\n    )\n}\n```\n\nOr per-test:\n\n```go\nfunc TestWorkerPool(t *testing.T) {\n    defer goleak.VerifyNone(t)\n    \u002F\u002F ... test code ...\n}\n```\n\n## testing\u002Fsynctest for Deterministic Goroutine Testing\n\n`testing\u002Fsynctest` (Go 1.25+) provides deterministic tests for goroutines, timers, deadlines, and context cancellation. Time advances only when all goroutines are blocked, making ordering predictable.\n\nWhen to use `synctest` instead of real time:\n\n- Testing concurrent code with time-based operations (time.Sleep, time.After, time.Ticker)\n- When race conditions need to be reproducible\n- When tests are flaky due to timing issues\n\n```go\nimport (\n    \"context\"\n    \"testing\"\n    \"testing\u002Fsynctest\"\n    \"time\"\n)\n\nfunc TestContextTimeout(t *testing.T) {\n    synctest.Test(t, func(t *testing.T) {\n        const timeout = 5 * time.Second\n\n        ctx, cancel := context.WithTimeout(t.Context(), timeout)\n        defer cancel()\n\n        time.Sleep(timeout - time.Nanosecond)\n        synctest.Wait()\n        if err := ctx.Err(); err != nil {\n            t.Fatalf(\"before timeout: %v\", err)\n        }\n\n        time.Sleep(time.Nanosecond)\n        synctest.Wait()\n        if err := ctx.Err(); err != context.DeadlineExceeded {\n            t.Fatalf(\"after timeout: got %v, want DeadlineExceeded\", err)\n        }\n    })\n}\n```\n\nUse `synctest.Test` in Go 1.25+ and Go 1.26+. Do not use the old Go 1.24 experimental `synctest.Run` API in Go 1.25+ or Go 1.26+ code. If a module explicitly targets Go 1.24 and opts into `GOEXPERIMENT=synctest`, use the old API only as a compatibility fallback.\n\nKey differences in `synctest`:\n\n- `time.Sleep` advances synthetic time instantly when the goroutine blocks\n- `time.After` fires when synthetic time reaches the duration\n- All goroutines run to blocking points before time advances\n- Test execution is deterministic and repeatable\n\n## Test Timeouts\n\nFor tests that may hang, use a timeout helper that panics with caller location. See [Helpers](.\u002Freferences\u002Fhelpers.md).\n\n## Benchmarks\n\n→ See `samber\u002Fcc-skills-golang@golang-benchmark` skill for advanced benchmarking: `b.Loop()` (Go 1.24+), `benchstat`, profiling from benchmarks, and CI regression detection.\n\nWrite benchmarks to measure performance and detect regressions:\n\n```go\nfunc BenchmarkStringConcatenation(b *testing.B) {\n    b.Run(\"plus-operator\", func(b *testing.B) {\n        for b.Loop() {\n            result := \"a\" + \"b\" + \"c\"\n            _ = result\n        }\n    })\n\n    b.Run(\"strings.Builder\", func(b *testing.B) {\n        for b.Loop() {\n            var builder strings.Builder\n            builder.WriteString(\"a\")\n            builder.WriteString(\"b\")\n            builder.WriteString(\"c\")\n            _ = builder.String()\n        }\n    })\n}\n```\n\nBenchmarks with different input sizes:\n\n```go\nfunc BenchmarkFibonacci(b *testing.B) {\n    sizes := []int{10, 20, 30}\n    for _, size := range sizes {\n        b.Run(fmt.Sprintf(\"n=%d\", size), func(b *testing.B) {\n            b.ReportAllocs()\n            for b.Loop() {\n                Fibonacci(size)\n            }\n        })\n    }\n}\n```\n\nFor Go 1.24+, new benchmarks should use `b.Loop()`. Use legacy `b.N` loops only when the module targets Go \u003C1.24 or when preserving old benchmark code intentionally.\n\n### Go 1.26+: test artifacts\n\nWhen a test, benchmark, or fuzz target needs to persist files for inspection, use `ArtifactDir()` instead of ad-hoc paths or repo-local output.\n\n```go\nfunc TestRenderGoldenArtifact(t *testing.T) {\n    dir := t.ArtifactDir()\n\n    out := filepath.Join(dir, \"rendered.json\")\n    if err := os.WriteFile(out, renderedBytes, 0o644); err != nil {\n        t.Fatal(err)\n    }\n\n    t.Logf(\"artifact written: %s\", out)\n}\n```\n\nAvailable on `*testing.T`, `*testing.B`, and `*testing.F` in Go 1.26+.\n\n## Parallel Tests\n\nUse `t.Parallel()` to run tests concurrently:\n\n```go\nfunc TestParallelOperations(t *testing.T) {\n    tests := []struct {\n        name string\n        data []byte\n    }{\n        {\"small data\", make([]byte, 1024)},\n        {\"medium data\", make([]byte, 1024*1024)},\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            t.Parallel()\n            is := assert.New(t)\n\n            result := Process(tt.data)\n            is.NotNil(result)\n        })\n    }\n}\n```\n\n## Fuzzing\n\nUse fuzzing to find edge cases and bugs:\n\n```go\nfunc FuzzReverse(f *testing.F) {\n    f.Add(\"hello\")\n    f.Add(\"\")\n    f.Add(\"a\")\n\n    f.Fuzz(func(t *testing.T, input string) {\n        reversed := Reverse(input)\n        doubleReversed := Reverse(reversed)\n        if input != doubleReversed {\n            t.Errorf(\"Reverse(Reverse(%q)) = %q, want %q\", input, doubleReversed, input)\n        }\n    })\n}\n```\n\n## Examples as Documentation\n\nExamples are executable documentation verified by `go test`:\n\n```go\nfunc ExampleCalculatePrice() {\n    price := CalculatePrice(100, 10.0)\n    fmt.Printf(\"Price: %.2f\\n\", price)\n    \u002F\u002F Output: Price: 900.00\n}\n\nfunc ExampleCalculatePrice_singleItem() {\n    price := CalculatePrice(1, 25.50)\n    fmt.Printf(\"Price: %.2f\\n\", price)\n    \u002F\u002F Output: Price: 25.50\n}\n```\n\n## Code Coverage\n\n```bash\n# Generate coverage file\ngo test -coverprofile=coverage.out .\u002F...\n\n# View coverage in HTML\ngo tool cover -html=coverage.out\n\n# Coverage by function\ngo tool cover -func=coverage.out\n\n# Total coverage percentage\ngo tool cover -func=coverage.out | grep total\n```\n\n## Integration Tests\n\nUse build tags to separate integration tests from unit tests:\n\n```go\n\u002F\u002Fgo:build integration\n\npackage mypackage\n\nfunc TestDatabaseIntegration(t *testing.T) {\n    db, err := sql.Open(\"postgres\", os.Getenv(\"DATABASE_URL\"))\n    if err != nil {\n        t.Fatal(err)\n    }\n    defer db.Close()\n\n    \u002F\u002F Test real database operations\n}\n```\n\nRun integration tests separately:\n\n```bash\ngo test -tags=integration .\u002F...\n```\n\nFor Docker Compose fixtures, SQL schemas, and integration test suites, see [Integration Testing](.\u002Freferences\u002Fintegration-testing.md).\n\n## Mocking\n\nMock interfaces, not concrete types. Define interfaces where consumed, then create mock implementations.\n\nFor mock patterns, test fixtures, and time mocking, see [Mocking](.\u002Freferences\u002Fmocking.md).\n\n## Enforce with Linters\n\nMany test best practices are enforced automatically by linters: `thelper`, `paralleltest`, `testifylint`. See the `samber\u002Fcc-skills-golang@golang-lint` skill for configuration and usage.\n\n## Cross-References\n\n- -> See `samber\u002Fcc-skills-golang@golang-stretchr-testify` skill for detailed testify API (assert, require, mock, suite)\n- -> See `samber\u002Fcc-skills-golang@golang-database` skill (testing.md) for database integration test patterns\n- -> See `samber\u002Fcc-skills-golang@golang-concurrency` skill for goroutine leak detection with goleak\n- -> See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for CI test configuration and GitHub Actions workflows\n- -> See `samber\u002Fcc-skills-golang@golang-lint` skill for testifylint and paralleltest configuration\n- -> See `samber\u002Fcc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines\n\n## Quick Reference\n\n```bash\ngo test .\u002F...                          # all tests\ngo test -run TestName .\u002F...            # specific test by exact name\ngo test -run TestName\u002Fsubtest .\u002F...    # subtests within a test\ngo test -run 'Test(Add|Sub)' .\u002F...     # multiple tests (regexp OR)\ngo test -run 'Test[A-Z]' .\u002F...         # tests starting with capital letter\ngo test -run 'TestUser.*' .\u002F...        # tests matching prefix\ngo test -run '.*Validation.*' .\u002F...    # tests containing substring\ngo test -run TestName\u002F. .\u002F...          # all subtests of TestName\ngo test -run '\u002F(unit|integration)' .\u002F... # filter by subtest name\ngo test -race .\u002F...                    # race detection\ngo test -cover .\u002F...                   # coverage summary\ngo test -bench=. -benchmem .\u002F...       # benchmarks\ngo test -fuzz=FuzzName .\u002F...           # fuzzing\ngo test -tags=integration .\u002F...        # integration tests\n```\n",{"name":5,"license":15,"metadata":54,"description":7,"allowed-tools":68,"compatibility":69,"user-invocable":70},{"author":55,"version":56,"openclaw":57},"samber","1.2.3",{"emoji":58,"install":59,"homepage":65,"requires":66},"🧪",[60],{"bins":61,"kind":63,"package":64},[62],"gotests","go","github.com\u002Fcweill\u002Fgotests\u002Fgotests@latest","https:\u002F\u002Fgithub.com\u002Fsamber\u002Fcc-skills-golang",{"bins":67},[63,62],"Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(gotests:*) AskUserQuestion","Designed for Claude Code or similar AI coding agents, and for projects using Golang.",true,"claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fgolang-testing","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":79,"prompt":89,"zipAvailable":70},[80,83,86],{"tool":81,"command":82},"npx","npx skills add pattanation\u002FNorvik --skill golang-testing",{"tool":84,"command":85},"bunx","bunx skills add pattanation\u002FNorvik --skill golang-testing",{"tool":87,"command":88},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill golang-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002FSKILL.md",[91,97,101,105,109],{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"evals\u002Fevals.json","REFERENCE","参考文档",21978,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002Fevals\u002Fevals.json",{"path":98,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fhelpers.md",1054,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002Freferences\u002Fhelpers.md",{"path":102,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fhttp-testing.md",2268,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002Freferences\u002Fhttp-testing.md",{"path":106,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fintegration-testing.md",4166,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002Freferences\u002Fintegration-testing.md",{"path":110,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fmocking.md",4573,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgolang-testing\u002Freferences\u002Fmocking.md",[114,143,169,192,214,229],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":118,"licenseFileUrl":119,"sourceHtmlUrl":120,"categories":121,"keywords":126,"publishedAt":142},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[122,123],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[127,29,128,129,130,131,132,40,133,134,135,136,137,138,139,140,141],"webapp","webapp testing","for","applications","local","frontend","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":118,"licenseFileUrl":147,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":142},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[150],{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},[152,153,154,138,155,156,157,129,158,159,132,160,161,162,163,164,165,166,167,168],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":173,"sourceHtmlUrl":174,"categories":175,"keywords":177,"publishedAt":142},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[176],{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},[178,179,180,181,182,183,184,185,186,187,188,189,190,191],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":196,"sourceHtmlUrl":197,"categories":198,"keywords":201,"publishedAt":142},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[199,200],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},[202,29,203,189,204,137,205,206,207,184,208,129,209,210,211,161,212,190,213],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":218,"sourceHtmlUrl":219,"categories":220,"keywords":222,"publishedAt":142},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[221],{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},[223,189,224,204,225,207,226,184,212,227,228],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":233,"sourceHtmlUrl":234,"categories":235,"keywords":237,"publishedAt":142},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[236],{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},[238,189,204,239,181,240,241,242,223,243,244,245,246,247,248,129,249,161,250,251],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]