← Back to Skills Marketplace
anderskev

Go Testing Code Review

by Kevin Anderson · GitHub ↗ · v2.3.1 · MIT-0
cross-platform ✓ Security Clean
188
Downloads
0
Stars
1
Active Installs
2
Versions
Install in OpenClaw
/install go-testing-code-review
Description
Reviews Go test code for proper table-driven tests, assertions, and coverage patterns. Use when reviewing *_test.go files.
README (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?
Usage Guidance
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.
Capability Analysis
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.
Capability Assessment
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.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install go-testing-code-review
  3. After installation, invoke the skill by name or use /go-testing-code-review
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
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.
Metadata
Slug go-testing-code-review
Version 2.3.1
License MIT-0
All-time Installs 1
Active Installs 1
Total Versions 2
Frequently Asked Questions

What is Go Testing Code Review?

Reviews Go test code for proper table-driven tests, assertions, and coverage patterns. Use when reviewing *_test.go files. It is an AI Agent Skill for Claude Code / OpenClaw, with 188 downloads so far.

How do I install Go Testing Code Review?

Run "/install go-testing-code-review" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Go Testing Code Review free?

Yes, Go Testing Code Review is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does Go Testing Code Review support?

Go Testing Code Review is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Go Testing Code Review?

It is built and maintained by Kevin Anderson (@anderskev); the current version is v2.3.1.

💬 Comments