AgentSkillsCN

go-test

为给定的代码或函数生成高质量的 Go 单元测试。

SKILL.md
--- frontmatter
name: go-test
description: Generate high-quality Go unit tests for the given code or function.
metadata:
  short-description: Generate table-driven Go unit tests with strong coverage.

Generate Go unit tests for the provided code using Go testing best practices.

Requirements

  • •Use table-driven tests for all testable functions.
  • •Each test case must:
    • •Have a clear and descriptive name.
    • •Explicitly define inputs, expected outputs, and error expectations.
  • •Use testing.T with t.Run for subtests.
  • •Use stretchr/testify:
    • •require for fatal assertions (setup, preconditions, returned errors).
    • •assert for value comparisons.
  • •Use mocking where appropriate:
    • •Prefer testify/mock for interface dependencies.
    • •Avoid real external dependencies (DB, network, filesystem).
  • •Focus on test coverage, including:
    • •Success cases
    • •Error cases
    • •Edge cases
    • •Boundary conditions
  • •Tests must be deterministic and translation-safe (no reliance on time, randomness, or global state unless mocked).
  • •Follow idiomatic Go conventions:
    • •File name: <file>_test.go
    • •Test name: Test<FunctionName>
  • •Always use English in test names and comments.
  • •Enforce minimum package coverage of 80%.
  • •Coverage must include:
    • •At least one error path per public function (if applicable).
    • •Boundary or edge cases where reasonable.

Output expectations

  • •Generate complete, compilable test code.
  • •Include necessary imports.
  • •Clearly separate:
    • •Arrange
    • •Act
    • •Assert
  • •Prefer readability to cleverness.
  • •Generated tests should realistically achieve ≥80% coverage when executed with: go test -cover ./...

Additional guidelines

  • •Prefer small, focused tests over large monolithic ones.
  • •If a function is hard to test:
    • •Explain briefly why
    • •Suggest a refactor (e.g., dependency injection).
  • •Do not test private implementation details—test behavior.
  • •Avoid snapshot-style assertions unless explicitly requested.
  • •If achieving ≥80% coverage is not possible without testing private implementation details:
    • •Explain the limitation briefly
    • •Suggest a refactor (interface extraction, dependency injection)
  • •Avoid fake coverage (e.g. meaningless assertions).