go-table-driven-tests

Create table-driven Go tests with slice and map patterns.

330|17|Updated Feb 12, 2015
One-click install
npx skills add https://github.com/Xe/x --skill go-table-driven-tests
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: go-table-driven-tests
Source: https://github.com/Xe/x/tree/main/.claude/skills/go-table-driven-tests
Command: npx skills add https://github.com/Xe/x --skill go-table-driven-tests

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Table-driven tests reduce duplication and improve maintainability in Go by consolidating many case checks into a single test harness, making tests easier to read and extend.

Core Features & Use Cases

  • Consolidates repetitive test cases into a single table and loop.
  • Supports slice-pattern tests for deterministic case ordering and map-pattern tests for non-deterministic orders.
  • Aligns with Go testing practices and repository conventions, improving consistency across tests.

Quick Start

Refactor a Go test to a table-driven pattern and run go test to verify all cases pass.

Frequently Asked Questions about go-table-driven-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce duplication in Go unit tests with multiple inputs?

Table-driven tests reduce duplication in Go unit tests by consolidating multiple inputs and edge cases into a single data structure looped through a test harness, ensuring consistent coverage and improved maintainability across your codebase.

What is the difference between slice-pattern and map-pattern tests in Go?

Slice-pattern tests in Go enforce deterministic case ordering by iterating through a slice of structs, while map-pattern tests allow non-deterministic execution orders, both supported by table-driven testing to structure repetitive case checks effectively.

How do I structure table-driven tests using t.Run subtests in Go?

Table-driven tests integrate with t.Run subtests in Go by looping through a cases table and passing each case's name to t.Run, creating isolated, readable subtest outputs that align with standard Go testing practices and repository conventions.

When should I refactor existing Go tests into a table-driven pattern?

Refactor Go tests into a table-driven pattern when testing functions with multiple inputs, varying behaviors, or numerous edge cases, consolidating repetitive case checks to improve test readability, maintainability, and consistent coverage across the codebase.

Does table-driven testing work with standard Go repository conventions?

Table-driven testing aligns with standard Go repository conventions for naming and structure, supporting both slice-pattern and map-pattern styles to ensure consistent test coverage and maintainability without conflicting with existing project practices.