Go Testing
Write and review Go tests with table-driven cases, subtests, helpers, and cmp.Diff failures you can diagnose without opening the test file.
Overview
Go Testing is an agent skill for the Ship phase that implements Google- and Uber-style Go unit test patterns with table-driven tests, subtests, and cmp.Diff assertions.
Install
npx skills add https://github.com/cxuu/golang-skills --skill go-testingWhat is this skill?
- Normative failure format: function name, inputs, got, want—aligned with Google/Uber style guidance
- Table-driven tests, subtests, parallel execution, t.Helper(), and t.Cleanup() patterns
- cmp.Diff for structs, slices, maps, and protos via google/go-cmp
- Clear t.Error vs t.Fatal guidance for setup versus assertion failures
- Explicitly excludes benchmark performance testing (defers to go-performance skill)
- Normative failure template: YourFunc(%v) = %v, want %v
- Sources cited: Google Style Guide and Uber Style Guide
Adoption & trust: 733 installs on skills.sh; 110 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Go tests are ad hoc, hard to debug on failure, or skip established table-driven and helper conventions.
Who is it for?
Indie Go backends and CLIs where you want style-guide-grade tests without memorizing t.Helper and cmp.Diff rules.
Skip if: Benchmark and performance regression work, non-Go stacks, or E2E browser testing.
When should I use this skill?
Writing, reviewing, or improving Go test code; user asks to write a test for a Go function; does not cover benchmarks (see go-performance).
What do I get? / Deliverables
You get maintainable Go tests with clear failure output and structure ready for CI review or merge.
- Table-driven or subtest-structured Go test code
- Review notes on failure message clarity and helper usage
Recommended Skills
Journey fit
Ship/testing is the canonical home for authoring and hardening unit and integration-style Go tests before release. Testing subphase captures normative patterns from Google and Uber Go style guides applied during CI and pre-ship review.
How it compares
Go-specific test style skill—not a generic TDD planner or JavaScript Vitest helper.
Common Questions / FAQ
Who is go-testing for?
Solo builders using Go who want agent help matching Google/Uber testing patterns when writing or reviewing *_test.go files.
When should I use go-testing?
During Ship testing whenever you add, fix, or review Go tests, including when you only ask for a test for one function.
Is go-testing safe to install?
Review the Security Audits panel on this page; the skill may run Bash to execute tests—scope commands to your repo.
SKILL.md
READMESKILL.md - Go Testing
# Go Testing ## Quick Reference | Pattern | Use When | |---------|----------| | `t.Error` | Default — report failure, keep running | | `t.Fatal` | Setup failed or continuing is meaningless | | `cmp.Diff` | Comparing structs, slices, maps, protos | | Table-driven | Many cases share identical logic | | Subtests | Need filtering, parallel execution, or naming | | `t.Helper()` | Any test helper function (call as first statement) | | `t.Cleanup()` | Teardown in helpers instead of defer | --- ## Useful Test Failures > **Normative**: Test failures must be diagnosable without reading the test > source. Every failure message must include: function name, inputs, actual (got), and expected (want). Use the format `YourFunc(%v) = %v, want %v`. ```go // Good: t.Errorf("Add(2, 3) = %d, want %d", got, 5) // Bad: Missing function name and inputs t.Errorf("got %d, want %d", got, 5) ``` Always print got before want: `got %v, want %v` — never reversed. --- ## No Assertion Libraries > **Normative**: Do not use assertion libraries. Use `cmp.Diff` for complex > comparisons. ```go if diff := cmp.Diff(want, got); diff != "" { t.Errorf("GetPost() mismatch (-want +got):\n%s", diff) } ``` For protocol buffers, add `protocmp.Transform()` as a cmp option. Always include the direction key `(-want +got)` in diff messages. Avoid comparing JSON/serialized output — compare semantically instead. > Read [references/TEST-HELPERS.md](references/TEST-HELPERS.md) when writing > custom comparison helpers or domain-specific test utilities. --- ## t.Error vs t.Fatal > **Normative**: Use `t.Error` by default to report all failures in one run. > Use `t.Fatal` only when continuing is impossible. **Choose `t.Fatal` when:** - Setup fails (DB connection, file load) - The next assertion depends on the previous one succeeding (e.g., decode after encode) **Never call `t.Fatal`/`t.FailNow` from a goroutine** other than the test goroutine — use `t.Error` instead. > Read [references/TEST-HELPERS.md](references/TEST-HELPERS.md) when writing > helpers that need to choose between t.Error and t.Fatal, or for detailed > examples of both. --- ## Table-Driven Tests > See `assets/table-test-template.go` when scaffolding a new table-driven test and need the canonical struct, loop, and subtest layout. > **Advisory**: Use table-driven tests when many cases share identical logic. **Use table tests when:** all cases run the same code path with no conditional setup, mocking, or assertions. A single `shouldErr` bool is acceptable. **Don't use table tests when:** cases need complex setup, conditional mocking, or multiple branches — write separate test functions instead. **Key rules:** - Use field names when cases span many lines or have same-type adjacent fields - Include inputs in failure messages — never identify rows by index > Read [references/TABLE-DRIVEN-TESTS.md](references/TABLE-DRIVEN-TESTS.md) > when writing table-driven tests, subtests, or parallel tests. > **Validation**: After generating or modifying tests, run `go test -run TestXxx -v` to verify the tests compile and pass. Fix any compilation errors before proceeding. --- ## Test Helpers > **Normative**: Test helpers must call `t.Helper()` first and use `t.Cleanup()` > for teardown. ```go func setupTestDB(t *testing.T) *sql.DB { t.Helper() db, err := sql.Open("sqlite3", ":memory:") if err != nil