Go test
A curated set of reusable Codex skills for common engineering tasks.
npx -y skills add geekswamp/agent-skills --skill go-testAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate deterministic, high-quality Go unit tests using table-driven patterns, infrastructure mocks, and project-specific helpers. Make sure to use this skill whenever the user mentions generating tests, writing test cases, increasing test coverage (aiming for ≥80%), or mocking dependencies like SQL (sqlmock), Redis (miniredis), or HTTP (Gin). It is optimized for table-driven test structures, deterministic data, and the mandatory use of the project's 'testutil' package. Use it for requests to create *_test.go files, implement unit tests for services or repositories, and ensure robust coverage of success and error paths.
SKILL.md
2.6 KB, as published. Nobody here has run it
Generate Go unit tests for the provided code using Go testing best practices.
Requirements
- Use table-driven tests for all testable functions.
- Use mocking where appropriate:
- Prefer
testify/mockfor interface dependencies. - Avoid real external dependencies (DB, network, filesystem).
- Prefer
- 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>
- File name:
- 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).
Please Read the References
- Detailed technical reference: REFERENCE.md.