Agent skill

Go Table Driven Tests

by Xe in Xe/x

Write Go table-driven tests following Go community best practices and this repository's conventions.

CC0-1.0Auto-check passedDevelopment

Install Go Table Driven Tests

skills CLI
$ npx skills add Xe/x --skill go-table-driven-tests -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Xe/x go-table-driven-tests --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Xe/x.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/go-table-driven-tests .claude/skills/go-table-driven-tests && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
go-table-driven-tests
GitHub stars
337
Token cost
~2k tokens
SKILL.md length
435 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
CC0-1.0

At a glance

Write Go table-driven tests following Go community best practices and this repository's conventions.

  • Works in 7 steps: Always use t.Run() for subtests - This… → Use descriptive test names - The name… → Test one thing per case - Each table… → …
  • Refactoring Go tests
  • SKILL.md covers Overview, When to Use Table-Driven Tests, Basic Template (Slice Pattern) and Map Pattern (For…, plus 7 more sections
  • Calls go

What it does

Go Table Driven Tests is an agent skill from Xe/x. Write Go table-driven tests following Go community best practices and this repository's conventions. Use when writing or refactoring Go tests, especially when you notice repeated test patterns or copy-pasted test code.

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Refactoring. The repository describes itself as: Various tools, trinkets and experiments. The licence is CC0-1.0.

When your agent uses it

  • Refactoring Go tests
  • Especially when you notice repeated test patterns
  • Copy-pasted test code

Example prompts

  • “/go-table-driven-tests”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Always use t.Run() for subtests - This is 100% consistent in this codebase
  2. Use descriptive test names - The name field should clearly describe what is being tested
  3. Test one thing per case - Each table entry should test one specific behavior
  4. Include edge cases - Empty strings, nil values, maximum values, etc.
  5. Use errors.Is for error comparison - Not == or reflect.DeepEqual
  6. Prefer t.Errorf over t.Fatalf - See all failures before stopping
  7. Keep test data inline - External files only for large golden test sets

What it can do on your machine

Read from SKILL.md and the folder at commit 42a5acb. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • go

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • go.dev
    • pkg.go.dev
    • dave.cheney.net

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Go Table Driven Tests loads about 2k tokens when it runs. Until then it costs about 60 tokens; SKILL.md has 435 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~60
When it runs · the whole SKILL.md, loaded when a task matches
~2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Xe/x at commit 42a5acb, republished under its CC0-1.0 licence (© Xe). 435 words, ~1,998 tokens.

Download SKILL.mdSave it as .claude/skills/go-table-driven-tests/SKILL.md (or your agent's skills folder).
name
go-table-driven-tests
description
Write Go table-driven tests following Go community best practices and this repository's conventions. Use when writing or refactoring Go tests, especially when you notice repeated test patterns or copy-pasted test code.

Go Table-Driven Tests

Overview

Table-driven tests are a Go testing idiom that reduces code duplication and makes tests more maintainable. Instead of writing separate test functions for each case, you define a table of test cases and iterate over it.

When to Use Table-Driven Tests

Use table-driven tests when:

  • You find yourself copying and pasting test code
  • You're testing the same function/behavior with multiple inputs
  • You want to add more test cases without writing more test functions
  • Edge cases and boundary conditions need systematic coverage

Do NOT use for: Completely unrelated test scenarios, or when each test requires substantially different setup/teardown logic.

Basic Template (Slice Pattern)

This is the most common pattern in this codebase:

go
func TestFunctionName(t *testing.T) {
    cases := []struct {
        name  string
        input string
        want  string
        err   error
    }{
        {
            name:  "simple case",
            input: "a/b/c",
            want:  "a,b,c",
        },
        {
            name:  "empty input",
            input: "",
            want:  "",
        },
        {
            name:  "invalid input",
            input: "!!!",
            want:  "",
            err:   ErrInvalid,
        },
    }

    for _, tt := range cases {
        t.Run(tt.name, func(t *testing.T) {
            got, err := FunctionName(tt.input)
            if !errors.Is(err, tt.err) {
                t.Errorf("FunctionName(%q) error = %v, want %v", tt.input, err, tt.err)
            }
            if got != tt.want {
                t.Errorf("FunctionName(%q) = %q, want %q", tt.input, got, tt.want)
            }
        })
    }
}

Map Pattern (For Non-Deterministic Test Ordering)

Use a map when you want to ensure test independence:

go
func TestFunctionName(t *testing.T) {
    tests := map[string]struct {
        input string
        want  string
    }{
        "simple case":   {input: "a/b/c", want: "a,b,c"},
        "empty input":   {input: "", want: ""},
        "trailing sep":  {input: "a/b/c/", want: "a,b,c"},
    }

    for name, tc := range tests {
        t.Run(name, func(t *testing.T) {
            got := FunctionName(tc.input)
            if got != tc.want {
                t.Fatalf("%s: expected %q, got %q", name, tc.want, got)
            }
        })
    }
}

Repository-Specific Conventions

Variable Naming

This codebase consistently uses these variable names:

PurposeVariable NameExample
Test cases slicecases, tt, cscases := []struct{...}
Loop variablett, cs, tcfor _, tt := range cases
Input fieldinput, in, inpinput: "test"
Expected outputwant, expectedwant: "result"
Actual outputgot, outputgot := Function()
Error fielderr, wantErrerr: ErrInvalid
Name fieldnamename: "descriptive name"
Struct Field Guidelines
go
// Always use named fields (not anonymous structs in this codebase)
cases := []struct {
    name      string  // Descriptive test name (REQUIRED when using slice pattern)
    input     Type    // Input to function under test
    want      Type    // Expected output
    err       error   // Expected error (use errors.Is for comparison)
    wantErr   bool    // Alternative: true if error is expected
    precondition func(*testing.T)  // Optional setup function
}{ ... }
Error Reporting

This repository uses these patterns:

go
// For error checking (preferred)
if !errors.Is(err, tt.err) {
    t.Errorf("error = %v, want %v", err, tt.err)
}

// For simple comparisons
if got != tt.want {
    t.Errorf("got %q, want %q", got, tt.want)
}

// Use t.Fatalf only when continuing doesn't make sense
// Use t.Errorf to see all test failures before stopping

Advanced Patterns

With Precondition Functions

When tests need specific setup:

go
for _, tt := range []struct {
    name         string
    precondition func(*testing.T)
    input        string
    err          error
}{
    {
        name: "with listener",
        precondition: func(t *testing.T) {
            ln, err := net.Listen("tcp", ":8081")
            if err != nil {
                t.Fatal(err)
            }
            t.Cleanup(func() { ln.Close() })
        },
        input: "test",
        err:   nil,
    },
} {
    t.Run(tt.name, func(t *testing.T) {
        if tt.precondition != nil {
            tt.precondition(t)
        }
        // test logic
    })
}
Parallel Tests

For independent tests that can run in parallel:

go
func TestFunctionName(t *testing.T) {
    cases := []struct {
        name  string
        input string
        want  string
    }{
        // ... test cases
    }

    for _, tt := range cases {
        tt := tt // Capture range variable (Go < 1.22)
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel() // Marks this subtest as parallel

            got := FunctionName(tt.input)
            if got != tt.want {
                t.Errorf("got %q, want %q", got, tt.want)
            }
        })
    }
}
Show full SKILL.md (211 more words)Show less

Best Practices

  1. Always use t.Run() for subtests - This is 100% consistent in this codebase
  2. Use descriptive test names - The name field should clearly describe what is being tested
  3. Test one thing per case - Each table entry should test one specific behavior
  4. Include edge cases - Empty strings, nil values, maximum values, etc.
  5. Use errors.Is for error comparison - Not == or reflect.DeepEqual
  6. Prefer t.Errorf over t.Fatalf - See all failures before stopping
  7. Keep test data inline - External files only for large golden test sets

Common Pitfalls to Avoid

  1. Forgetting t.Run() - Without subtests, all failures appear at the same line
  2. Using Fatalf immediately - You won't see other test failures
  3. Not capturing range variable - In Go < 1.22, add tt := tt before t.Run
  4. Anonymous structs - This codebase prefers named structs for clarity
  5. Inconsistent naming - Stick to the conventions (cases, tt, want, got)

Comparison with Traditional Tests

TraditionalTable-Driven
func TestFoo(t *testing.T) { ... }func TestFoo(t *testing.T) { cases := []struct{...}{...} }
One test function per caseSingle function, many cases
Hard to add new casesJust add a row to the table
Verbose boilerplateConcise, DRY code
go test -run TestFoo_SpecificCasego test -run TestFoo/name

Running Specific Tests

bash
# Run all tests in a function
go test -run TestFunctionName

# Run a specific subtest
go test -run TestFunctionName/descriptive_name

# Run all tests matching a pattern
go test -run TestFunctionName/.*/empty

# Verbose mode (see all test output)
go test -v

# Run with race detector
go test -race

References

© Xe, CC0-1.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/go-table-driven-tests of Xe/x.

Open the folder on GitHubat commit 42a5acb

Compare with similar skills

Go Table Driven Tests next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Go Table Driven Tests compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Go Table Driven Tests this skillXe/x337—~2kAutomated safety check: PassCC0-1.0
Guidelinesakash-network/node1.1k22 repos~577Automated safety check: PassMIT
Component Refactoringlangflow-ai/langflow156k—~3.5kAutomated safety check: PassMIT
Migrate Core Code to Submodulestinyhumansai/openhuman42k—~2.6kAutomated safety check: PassGPL-3.0
Systematic Code Refactoringluongnv89/claude-howto42k—~3kAutomated safety check: PassMIT
Codexskills-directory/skill-codex1.5k3 repos~1.8kAutomated safety check: PassMIT

Similar skills

  • Guidelines

    akash-network/node

    Behavioral guidelines to reduce common LLM coding mistakes. An agent skill from akash-network/node.

    1.1k GitHub starsUsed in 22 repos~577 tokens
    DevelopmentAuto-check passed
  • Component Refactoring

    langflow-ai/langflow

    Refactor high-complexity React components in Langflow frontend.

    156k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check passed
  • Migrate Core Code to Submodules

    tinyhumansai/openhuman

    Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.

    42k GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed
  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated 7 days ago
    DevelopmentAuto-check passed
  • Codex

    skills-directory/skill-codex

    A skill your agent uses when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing

    1.5k GitHub starsUsed in 3 repos~1.8k tokens
    DevelopmentAuto-check passed
  • Ponytail

    DavidObando/gsharp

    Forces the laziest solution that actually works, simplest, shortest, most minimal.

    565 GitHub starsUsed in 8 repos~1.7k tokens
    DevelopmentAuto-check passed

More from Xe/x

  • Transform unstructured notes into polished blog posts in Xe Iaso's voice.

    337 GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Build interactive hypermedia-driven applications with templ and HTMX.

    337 GitHub stars~3.3k tokensUpdated today
    Auto-check passed
  • Write Go code following the conventions and patterns used in the within.website/x repository, including CLI patterns with internal.HandleStartup(), error handling, logging with slog, HTTP handlers…

    337 GitHub stars~2k tokensUpdated today
    Auto-check passed

Categories

Questions about Go Table Driven Tests

What does Go Table Driven Tests do?

Write Go table-driven tests following Go community best practices and this repository's conventions. Go Table Driven Tests is an agent skill from Xe/x. Write Go table-driven tests following Go community best practices and this repository's conventions.

When should I use Go Table Driven Tests?

Go Table Driven Tests fits situations like: refactoring Go tests; especially when you notice repeated test patterns; copy-pasted test code.

How do I install Go Table Driven Tests in Claude Code?

Run `npx skills add Xe/x --skill go-table-driven-tests -a claude-code`. Or copy the skill folder (.claude/skills/go-table-driven-tests in Xe/x) into .claude/skills/go-table-driven-tests in your project. Claude Code loads it when a task matches its description.

How do I install Go Table Driven Tests in Codex?

Run `npx skills add Xe/x --skill go-table-driven-tests -a codex`. Or copy the skill folder (.claude/skills/go-table-driven-tests in Xe/x) into .agents/skills/go-table-driven-tests in your project. Codex loads it when a task matches its description.

Can I use Go Table Driven Tests in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Xe/x --skill go-table-driven-tests -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/go-table-driven-tests, .gemini/skills/go-table-driven-tests, .github/skills/go-table-driven-tests and .opencode/skills/go-table-driven-tests in your project.

What does Go Table Driven Tests need to run?

Going by SKILL.md and its folder, Go Table Driven Tests needs the command-line tools its instructions call (go).

Does Go Table Driven Tests access the network?

SKILL.md names 3 domains. As links in the text: go.dev, pkg.go.dev and dave.cheney.net. This is read from the text; nothing was executed.

Is Go Table Driven Tests safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Go Table Driven Tests use?

Go Table Driven Tests is published under the CC0-1.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Go Table Driven Tests use?

About 2k tokens (SKILL.md is roughly 8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Go Table Driven Tests?

Skills that share tags, products or a category with Go Table Driven Tests: Guidelines (akash-network/node, 1.1k stars), Component Refactoring (langflow-ai/langflow, 156k stars), Migrate Core Code to Submodules (tinyhumansai/openhuman, 42k stars) and Systematic Code Refactoring (luongnv89/claude-howto, 42k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Go Table Driven Tests?

Xe (a GitHub user) maintains it in Xe/x, which has 337 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 8, 2026.

Source: Xe/x on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.