← 返回 Skills 市场
anderskev

Go Testing Code Review

作者 Kevin Anderson · GitHub ↗ · v2.3.1 · MIT-0
cross-platform ✓ 安全检测通过
188
总下载
0
收藏
1
当前安装
2
版本数
在 OpenClaw 中安装
/install go-testing-code-review
功能描述
Reviews Go test code for proper table-driven tests, assertions, and coverage patterns. Use when reviewing *_test.go files.
使用说明 (SKILL.md)

Go Testing Code Review

Review Workflow

Follow this sequence in order. Do not emit findings until every Pass below is satisfied.

  1. Baseline go.mod — Open go.mod for the module under review and read the go directive.
    Pass: You can state the exact go X.YY value (in the review preamble or working notes). Apply version-gated advice only when it matches this baseline (e.g. fuzz tests Go 1.18+, loop-variable capture pre-Go 1.22).

  2. Read surrounding tests — For each *_test.go (or benchmark/fuzz file) in scope, read full test functions and any table struct{...} / helpers they use, not only the diff hunk.
    Pass: At least one full func Test... / func Benchmark... / func Fuzz... (or helper it calls) containing the change was read per in-scope file.

  3. Scope the checklist — Decide which Review Checklist rows apply (table-driven structure, parallelism, HTTP, golden files, mocks). Open references/structure.md and/or references/mocking.md for those topics; skip rows N/A to the diff with a one-line reason (e.g. “no t.Parallel in change”).
    Pass: The review (or working notes) lists which checklist themes you applied, or marks themes N/A with a diff-tied reason.

  4. Pre-report verification — Load and follow review-verification-protocol.
    Pass: The protocol’s Pre-Report Verification Checklist is satisfied for each finding you will report (actual test code read, surrounding context checked, “wrong” vs “different style” distinguished, etc.).

Hard gates (same sequence, shorter)

Step Objective pass condition
1 go X.YY from go.mod is recorded before version-specific test advice.
2 Full enclosing test (or helper it uses) read per in-scope test file, not diff-only.
3 In-scope checklist themes listed or N/A with diff-tied reason; references opened as needed.
4 review-verification-protocol completed for every reported issue.

Output Format

Report findings as:

[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.

Quick Reference

Issue Type Reference
Test structure, naming references/structure.md
Mocking, interfaces references/mocking.md

Review Checklist

  • Tests are table-driven with clear case names
  • Subtests use t.Run for parallel execution
  • Test names describe behavior, not implementation
  • Errors include got/want with descriptive message
  • Cleanup registered with t.Cleanup
  • Parallel tests don't share mutable state
  • Mocks use interfaces defined in test file
  • Coverage includes edge cases and error paths
  • Performance-critical functions have Benchmark* tests
  • Input parsers/validators have Fuzz* tests (Go 1.18+)
  • HTTP handlers tested with httptest.NewRequest/httptest.NewRecorder
  • Golden file tests use testdata/*.golden pattern with -update flag

Critical Patterns

Table-Driven Tests

// BAD - repetitive
func TestAdd(t *testing.T) {
    if Add(1, 2) != 3 {
        t.Error("wrong")
    }
    if Add(0, 0) != 0 {
        t.Error("wrong")
    }
}

// GOOD
func TestAdd(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        want     int
    }{
        {"positive numbers", 1, 2, 3},
        {"zeros", 0, 0, 0},
        {"negative", -1, 1, 0},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Add(tt.a, tt.b)
            if got != tt.want {
                t.Errorf("Add(%d, %d) = %d, want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

Error Messages

// BAD
if got != want {
    t.Error("wrong result")
}

// GOOD
if got != want {
    t.Errorf("GetUser(%d) = %v, want %v", id, got, want)
}

// For complex types
if diff := cmp.Diff(want, got); diff != "" {
    t.Errorf("GetUser() mismatch (-want +got):\
%s", diff)
}

Parallel Tests

func TestFoo(t *testing.T) {
    tests := []struct{...}

    for _, tt := range tests {
        tt := tt  // capture (not needed Go 1.22+)
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            // test code
        })
    }
}

Cleanup

// BAD - manual cleanup, skipped on failure
func TestWithTempFile(t *testing.T) {
    f, _ := os.CreateTemp("", "test")
    defer os.Remove(f.Name())  // skipped if test panics
}

// GOOD
func TestWithTempFile(t *testing.T) {
    f, _ := os.CreateTemp("", "test")
    t.Cleanup(func() {
        os.Remove(f.Name())
    })
}

Additional Patterns

Benchmarks

func BenchmarkProcess(b *testing.B) {
    data := generateTestData(1000)
    b.ResetTimer()

    for i := 0; i \x3C b.N; i++ {
        Process(data)
    }
}

// Run: go test -bench=BenchmarkProcess -benchmem

Fuzz Tests (Go 1.18+)

func FuzzParseInput(f *testing.F) {
    // Seed corpus
    f.Add(`{"name": "test"}`)
    f.Add(``)
    f.Add(`{invalid}`)

    f.Fuzz(func(t *testing.T, input string) {
        result, err := ParseInput(input)
        if err != nil {
            return // invalid input is expected
        }
        // If parsing succeeded, re-encoding should work
        if _, err := json.Marshal(result); err != nil {
            t.Errorf("Marshal after Parse: %v", err)
        }
    })
}

// Run: go test -fuzz=FuzzParseInput -fuzztime=30s

HTTP Handler Tests

func TestHandler(t *testing.T) {
    srv := NewServer(mockDeps)

    req := httptest.NewRequest("GET", "/api/users/123", nil)
    w := httptest.NewRecorder()

    srv.ServeHTTP(w, req)

    if w.Code != http.StatusOK {
        t.Errorf("status = %d, want %d", w.Code, http.StatusOK)
    }
}

Golden Files

var update = flag.Bool("update", false, "update golden files")

func TestRender(t *testing.T) {
    got := Render(input)
    golden := filepath.Join("testdata", t.Name()+".golden")

    if *update {
        if err := os.WriteFile(golden, got, 0644); err != nil {
            t.Fatalf("writing golden file: %v", err)
        }
    }

    want, err := os.ReadFile(golden)
    if err != nil {
        t.Fatalf("reading golden file: %v (run with -update to create)", err)
    }
    if !bytes.Equal(got, want) {
        t.Errorf("output mismatch:\
got:\
%s\
want:\
%s", got, want)
    }
}

Anti-Patterns

1. Testing Internal Implementation

// BAD - tests private state
func TestUser(t *testing.T) {
    u := NewUser("alice")
    if u.id != 1 {  // testing internal field
        t.Error("wrong id")
    }
}

// GOOD - tests behavior
func TestUser(t *testing.T) {
    u := NewUser("alice")
    if u.ID() != 1 {
        t.Error("wrong ID")
    }
}

2. Shared Mutable State

// BAD - tests interfere with each other
var testDB = setupDB()

func TestA(t *testing.T) {
    t.Parallel()
    testDB.Insert(...)  // race!
}

// GOOD - isolated per test
func TestA(t *testing.T) {
    db := setupTestDB(t)
    t.Cleanup(func() { db.Close() })
    db.Insert(...)
}

3. Assertions Without Context

// BAD
assert.Equal(t, want, got)  // "expected X got Y" - which test?

// GOOD
assert.Equal(t, want, got, "user name after update")

When to Load References

  • Reviewing test file structure → structure.md
  • Reviewing mock implementations → mocking.md

Review Questions

  1. Are tests table-driven with named cases?
  2. Do error messages include input, got, and want?
  3. Are parallel tests isolated (no shared state)?
  4. Is cleanup done via t.Cleanup?
  5. Do tests verify behavior, not implementation?
安全使用建议
This skill appears coherent for reviewing Go tests: it reads go.mod and test files and uses included reference docs. Before installing, confirm you are comfortable letting the agent read your repository files (tests, go.mod, testdata) because the skill requires reading entire tests and surrounding helpers. Also note the SKILL.md expects a ../review-verification-protocol/SKILL.md file which is not bundled — ask the skill author for that protocol or ensure your environment provides an equivalent verification checklist to avoid runtime errors or ambiguous verification steps.
功能分析
Type: OpenClaw Skill Name: go-testing-code-review Version: 2.3.1 The skill is a standard code review tool for Go testing, providing a structured workflow and comprehensive checklists for evaluating table-driven tests, mocking, and performance benchmarks. It includes detailed reference documentation (references/mocking.md and references/structure.md) that aligns with Go best practices and contains no indicators of malicious intent, data exfiltration, or unauthorized execution.
能力评估
Purpose & Capability
Name/description match the behavior: the SKILL.md explicitly instructs the agent to read go.mod and *_test.go files and apply Go testing best-practices. There are no unrelated binaries, env vars, or credentials requested.
Instruction Scope
Instructions correctly require reading repository files (go.mod, full test functions, helpers) which is necessary for a code-reviewer. Two notable caveats: (1) the SKILL.md mandates following a `review-verification-protocol` at ../review-verification-protocol/SKILL.md — that file is not present in this bundle and could cause the protocol step to fail or be ambiguous at runtime; (2) the skill explicitly requires reading whole files across the repo (not just diffs), which is expected for a review but means the agent will access potentially sensitive code and testdata in the workspace.
Install Mechanism
Instruction-only skill with no install spec and no code to write to disk. Lowest-risk install posture.
Credentials
No environment variables, credentials, or config paths are requested. The skill does ask the agent to open files in the repository (go.mod and test files), which is appropriate for the stated purpose.
Persistence & Privilege
always is false and model invocation is allowed (default). The skill does not request persistent presence or modify other skills/system settings.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install go-testing-code-review
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /go-testing-code-review 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v2.3.1
Major update: Introduces a strict review sequence and verification gates to standardize and improve review quality. - Added a required 4-step review workflow: baseline Go version, read full context, scope checklist, complete pre-report verification. - Introduced “Hard gates” table summarizing mandatory review objectives. - Now mandates referencing and applying only checklist items relevant to the diff, with N/A reasoning for skipped items. - Requires use of an external “review-verification-protocol” before reporting findings. - Output reporting format is now specified and standardized. - Existing checklist and patterns retained, with new instructions for workflow discipline and compliance.
v2.3.0
- Added comprehensive review checklist for Go test code, covering table-driven, parallel, and fuzz tests. - Expanded documentation with anti-patterns, critical testing patterns, and example code snippets. - Included references for structure and mocking best practices. - Clarified best practices for error messages, cleanup, and isolation in tests. - Added guidance for benchmarks, fuzz tests, HTTP handlers, and golden files.
元数据
Slug go-testing-code-review
版本 2.3.1
许可证 MIT-0
累计安装 1
当前安装数 1
历史版本数 2
常见问题

Go Testing Code Review 是什么?

Reviews Go test code for proper table-driven tests, assertions, and coverage patterns. Use when reviewing *_test.go files. 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 188 次。

如何安装 Go Testing Code Review?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install go-testing-code-review」即可一键安装,无需额外配置。

Go Testing Code Review 是免费的吗?

是的,Go Testing Code Review 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

Go Testing Code Review 支持哪些平台?

Go Testing Code Review 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 Go Testing Code Review?

由 Kevin Anderson(@anderskev)开发并维护,当前版本 v2.3.1。

💬 留言讨论