test-go

Write Go tests that verify behavior through public APIs using behavior-driven testing principles.

5|Updated Sep 9, 2017
One-click install
npx skills add https://github.com/hpcsc/dotfiles --skill test-go-hpcsc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-go
Source: https://github.com/hpcsc/dotfiles/tree/main/link/common/claude/.claude/skills/test-go
Command: npx skills add https://github.com/hpcsc/dotfiles --skill test-go-hpcsc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing Go tests often drifts toward testing implementation details, producing brittle tests that break on refactors and fail to verify real behavior. This Skill guides the AI to write behavior-driven Go tests that assert on observable outcomes through public APIs, with one behavior per test and expected values derived from domain knowledge rather than the code under test. ## Core Features & Use Cases - Behavior-Driven Test Planning: Presents a test plan before writing code, listing what each test verifies, where expected values come from, and what code change would cause each test to fail. - Caller Pattern Classification: Classifies the component under test (UI, Inbound, Outbound, Async Processing, Exported API) to determine what to assert on versus ignore. - Structured Test Templates: Provides Arrange-Act-Assert table-driven test structures using testify's require package, with guidance on when to expose or hide test details. - Use Case: You have a Go account service with a Withdraw method. Ask the AI to write tests, and it produces subtests like "fails with insufficient funds" that assert on error messages from business rules, never touching internal state. ## Quick Start Write behavior-driven tests for my Go file account.go following the test-go guidelines.

Frequently Asked Questions about test-go

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

FAQPage Schema
How do I write behavior-driven tests in Go?▼

Write behavior-driven Go tests by asserting on observable outcomes through public APIs, using table-driven subtests with an Arrange-Act-Assert structure. Each test should verify one behavior with expected values derived from domain knowledge, not from the code under test.

How to structure Go unit tests with subtests?▼

Structure Go unit tests with a top-level TestFeatureName function containing t.Run subtests for each scenario. Each subtest follows Arrange-Act-Assert: set up visible test data, execute through the public API, then assert with require.NoError or require.EqualError.

Should Go tests access private functions or internals?▼

No, Go tests should never expose or test internals. Test as a regular client would through the public API only, verifying what the code does rather than how it does it, so tests survive refactors of implementation details.

What is a caller pattern in Go testing?▼

A caller pattern classifies the component under test as UI (read queries, JSON APIs), Inbound (state-changing commands), Outbound, Async Processing, or Exported API. The classification determines which outcomes to assert on and which details to ignore.

When should Go tests use strict vs loose assertions?▼

Use strict assertions like require.EqualError when the exact error message is part of the contract a caller depends on. Use looser assertions when details are incidental, balancing clarity so each test has a single reason to fail.