go-table-driven-tests_skill

Overview

This skill generates idiomatic Go table-driven tests following Go community best practices and the repository's conventions. It helps replace repeated test code with concise tables, making tests easier to read, extend, and maintain. Use it to standardize test naming, error checks, and common patterns across the codebase.

How this skill works

Given a function signature and example behaviors, the skill builds a table of test cases using the preferred slice or map pattern and emits a complete test function. It annotates fields like name, input, want, and err, inserts precondition and parallel options when needed, and applies the repository's variable naming and error-checking conventions. The output is ready to paste into _test.go files and run with standard go test commands.

When to use it

• When tests contain copy-pasted or repetitive assertions for the same behavior
• When adding many input/output combinations or edge cases to a function
• When refactoring tests to improve clarity and reduce boilerplate
• When you want consistent naming, error handling, and subtest use across the repo
• When converting legacy tests into subtests that can run in parallel

Best practices

• Always wrap cases with t.Run(tt.name, ...) so failures show per-subtest
• Use descriptive name fields and test one behavior per case
• Prefer errors.Is for error comparison and t.Errorf to collect failures
• Capture the range variable (tt := tt) before t.Run when running subtests in parallel
• Keep test data inline; use precondition funcs for setup and t.Cleanup for teardown

Example use cases

• Create table-driven tests for a string parsing function with normal, empty, and invalid inputs
• Refactor multiple near-identical test functions into one table with cases for each scenario
• Add parallelized subtests for independent cases to speed up the test suite
• Introduce precondition functions for cases that need network listeners or temporary files
• Write map-based tests when you need nondeterministic ordering and independent cases