apply-go-test-convention

Writes Go table-driven tests following shared conventions for structure, case identity, and assertions.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill apply-go-test-convention-nakamori-naoya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: apply-go-test-convention
Source: https://github.com/nakamori-naoya/go-convention-plugins/tree/main/plugins/go-convention/skills/apply-go-test-convention
Command: npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill apply-go-test-convention-nakamori-naoya

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Go test code often drifts into inconsistent shapes across packages: split test functions, missing case identifiers, boolean error checks, and ad-hoc setup helpers. This Skill enforces one uniform test shape across all layers so any test reads the same way and stays traceable to BDD specifications in design documents. ## Core Features & Use Cases - Uniform test structure: One test function per method or function, external {pkg}_test packages, anonymous-struct table-driven tests, and a single execution/verification loop. - BDD traceability: Copies document BDD IDs, headings, and gherkin blocks verbatim into id / name / description fields, with untested BDDs listed as trailing comments. - Mechanical verification: Ships scripts/check-cases.py to validate package naming, unique IDs and names, and gherkin structure, alongside go vet and go test -shuffle=on. - Use Case: Given a domain-model document with BDD-014 scenarios, write a repository or usecase test where each case carries the document's ID and gherkin, then run the checker to confirm structural compliance. ## Quick Start Write tests for this Go method following the test convention, mapping each BDD scenario from the attached design document into table cases.

Frequently Asked Questions about apply-go-test-convention

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

FAQPage Schema
How do I write table-driven tests in Go with testify?▼

Define an anonymous struct slice with id, name, description, Given, When, and Then fields in that order, then run one loop with t.Run using tt.id and tt.name. Use require for preconditions like NoError and assert for independent expectations like Equal.

How to map BDD scenarios from design documents into Go test cases?▼

Copy the document's BDD ID verbatim into the id field, the heading into name, and the gherkin block unmodified into a raw-string description. BDDs you choose not to test go in a trailing comment with reasons, so every document ID appears either as a case or an exclusion.

Should Go tests use internal or external test packages?▼

This convention requires external {pkg}_test packages so private functions and fields stay unreachable. Testing only the public API keeps tests green through internal refactors; export_test.go is explicitly disallowed.

Why use wantErr error instead of boolean error checks in Go tests?▼

Boolean flags like shouldFail pass on any error, including unrelated failures, and string matching breaks on message changes. Storing a sentinel error in wantErr and checking with require.ErrorIs verifies the exact expected failure.

When should a Go table test use a setup function field?▼

Use setup func(t *testing.T) fixture only when Given needs t (TempDir, Cleanup, transactions) or non-serializable resources like DB handles, and only when it differs per case. Otherwise express Given as plain data fields.

What are the limitations of the check-cases.py structural checker?▼

It verifies five predicates: external test package, unique non-empty ids, adjacent id/name/description lines, unique names, and gherkin heading order. It cannot judge whether tests are table-driven, correct, or cover all document BDDs; that requires human review and layer-specific checks.