Agent skill · software engineering · affaan-m
golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices. Use when writing Go tests — table-driven cases, subtests, benchmarks, fuzzing, or coverage.
Why this skill is useful
Provides specific Go testing patterns and TDD methodologies that enhance the AI's ability to generate idiomatic Go test code.
What it needs
About 8k tokens when loaded. Last updated 2026-08-06. 238,342 stars on the source repository.
What this skill does
Go Testing Patterns Comprehensive Go testing patterns for writing reliable, maintainable tests following TDD methodology. When to Activate Writing new Go functions or methods Adding test coverage to existing code Creating benchmarks for performance-critical code Implementing fuzz tests for input validation Following TDD workflow in Go projects TDD Workflow for Go The RED-GREEN-REFACTOR Cycle Step-by-Step TDD in Go Table-Driven Tests The standard pattern for Go tests. Enables comprehensive coverage with minimal code. Table-Driven Tests with Error Cases Subtests and Sub-benchmarks Organizing Related Tests Parallel Subtests Test Helpers Helper Functions Temporary Files and Directories Golden Files Testing against expected output files stored in testdata/. Mocking with Interfaces Interface-Based Mocking Benchmarks Basic Benchmarks Benchmark with Different Sizes Memory Allocation Benchmarks Fuzzing (Go 1.18+) Basic Fuzz Test Fuzz Test with Multiple Inputs Test Coverage Running Coverage Coverage Targets Code Type Target ----------- -------- Critical business logic 100% Public APIs 90%+ General code 80%+ Generated code Exclude Excluding Generated Code from Coverage HTTP Handler Testing Testing Commands Best Practices DO: Write tests FIRST (TDD) Use table-driven tests for comprehensive coverage Test behavior, not implementation Use t.Helper() in helper functions Use t.Parallel() for independent tests Clean up resources with t.Cleanup() Use meaningful test names that describe the scenario DON'T: Test private functions directly (test through public API) Use time.Sleep() in tests (use channels or conditions) Ignore flaky tests (fix or remove them) Mock everything (prefer integration tests when possible) Skip error path testing Integration with CI/CD Remember: Tests are documentation. They show how your code is meant to be used. Write them clearly and keep them up to date.
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills affaan-m/golang-testing--4dd20c