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.

By affaan-m · 3,055 installs

npx skills add affaan-m/ecc --skill golang-testing

Source repository · Upstream listing

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.