
Golang Testing
Ship reliable Go services by following RED-GREEN-REFACTOR TDD with table-driven tests, subtests, benchmarks, fuzzing, and coverage habits.
Overview
Golang-testing is an agent skill most often used in Ship (also Build/backend) that teaches Go TDD and idiomatic patterns including table-driven tests, subtests, benchmarks, and fuzzing.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill golang-testingWhat is this skill?
- Documents the full RED-GREEN-REFACTOR TDD cycle with concrete Go examples
- Idiomatic table-driven tests and subtests for many inputs in one case
- Benchmarks for performance-critical paths and fuzz tests for validation edge cases
- Step-by-step workflow from failing test through minimal green implementation
- Aligns with maintainable Go test packages and coverage-oriented habits
- RED-GREEN-REFACTOR cycle with six documented TDD steps in Go
Adoption & trust: 7.6k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are building or extending Go code but tests are ad hoc, missing edge cases, or written only after implementation, so refactors and agent changes feel risky.
Who is it for?
Solo builders maintaining Go packages who want agent-assisted TDD and standard Go test layout before merging.
Skip if: Teams that only need language-agnostic integration or E2E test strategy with no Go `testing` package work.
When should I use this skill?
Writing new Go functions or methods, adding test coverage, creating benchmarks, implementing fuzz tests, or following TDD workflow in Go projects.
What do I get? / Deliverables
After the skill runs, you have failing-first tests, minimal green implementations, and repeatable `go test` workflows including benchmarks and fuzz where appropriate.
- Idiomatic `*_test.go` files with table-driven and subtests
- Passing `go test` suite with optional benchmarks and fuzz targets
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill’s primary artifact is test code and verification commands (`go test`, benchmarks, fuzz) before release. Testing subphase matches TDD activation triggers: new functions, added coverage, performance benchmarks, and input-validation fuzz tests.
Where it fits
Implement a new Go handler with a failing table-driven test before any production logic lands.
Backfill subtests and fuzz cases on a parser before tagging a release.
Add benchmarks around a allocation-heavy code path to catch regressions in CI.
How it compares
Use for procedural Go TDD and idiomatic unit tests instead of generic “write some tests” chat without RED-GREEN-REFACTOR structure.
Common Questions / FAQ
Who is golang-testing for?
Indie and solo developers shipping Go backends, CLIs, or services who want their coding agent to follow TDD and idiomatic Go test patterns.
When should I use golang-testing?
In Build/backend while implementing new functions, and in Ship/testing when adding coverage, benchmarks for hot paths, or fuzz tests before release.
Is golang-testing safe to install?
Review the Security Audits panel on this Prism page for this skill’s source repo; the skill itself guides local `go test` and does not require embedding secrets in prompts.
SKILL.md
READMESKILL.md - Golang Testing
# Go Testing Patterns Comprehensive Go testing patterns for writing reliable, maintainable tests following TDD methodology. ## When to Activate - Writing new Go functions or methods - Adding test coverage to existing code - Creating benchmarks for performance-critical code - Implementing fuzz tests for input validation - Following TDD workflow in Go projects ## TDD Workflow for Go ### The RED-GREEN-REFACTOR Cycle ``` RED → Write a failing test first GREEN → Write minimal code to pass the test REFACTOR → Improve code while keeping tests green REPEAT → Continue with next requirement ``` ### Step-by-Step TDD in Go ```go // Step 1: Define the interface/signature // calculator.go package calculator func Add(a, b int) int { panic("not implemented") // Placeholder } // Step 2: Write failing test (RED) // calculator_test.go package calculator import "testing" func TestAdd(t *testing.T) { got := Add(2, 3) want := 5 if got != want { t.Errorf("Add(2, 3) = %d; want %d", got, want) } } // Step 3: Run test - verify FAIL // $ go test // --- FAIL: TestAdd (0.00s) // panic: not implemented // Step 4: Implement minimal code (GREEN) func Add(a, b int) int { return a + b } // Step 5: Run test - verify PASS // $ go test // PASS // Step 6: Refactor if needed, verify tests still pass ``` ## Table-Driven Tests The standard pattern for Go tests. Enables comprehensive coverage with minimal code. ```go func TestAdd(t *testing.T) { tests := []struct { name string a, b int expected int }{ {"positive numbers", 2, 3, 5}, {"negative numbers", -1, -2, -3}, {"zero values", 0, 0, 0}, {"mixed signs", -1, 1, 0}, {"large numbers", 1000000, 2000000, 3000000}, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { got := Add(tt.a, tt.b) if got != tt.expected { t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.expected) } }) } } ``` ### Table-Driven Tests with Error Cases ```go func TestParseConfig(t *testing.T) { tests := []struct { name string input string want *Config wantErr bool }{ { name: "valid config", input: `{"host": "localhost", "port": 8080}`, want: &Config{Host: "localhost", Port: 8080}, }, { name: "invalid JSON", input: `{invalid}`, wantErr: true, }, { name: "empty input", input: "", wantErr: true, }, { name: "minimal config", input: `{}`, want: &Config{}, // Zero value config }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { got, err := ParseConfig(tt.input) if tt.wantErr { if err == nil { t.Error("expected error, got nil") } return } if err != nil { t.Fatalf("unexpected error: %v", err) } if !reflect.DeepEqual(got, tt.want) { t.Errorf("got %+v; want %+v", got, tt.want) } }) } } ``` ## Subtests and Sub-benchmarks ### Organizing Related Tests ```go func TestUser(t *testing.T) { // Setup shared by all subtests db := setupTestDB(t) t.Run("Create", func(t *testing.T) { user := &User{Name: "Alice"} err := db.CreateUser(user) if err != nil { t.Fatalf("CreateUser failed: %v", err) } if user.ID == "" { t.Error("expected user ID t