- Home
- Skills
- Jovermier
- Cc Stack Marketplace
- Go Testing
go-testing_skill
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill jovermier/cc-stack-marketplace --skill go-testing- SKILL.md5.3 KB
Overview
This skill teaches Go testing best practices focused on maintainability and reliability. It covers table-driven tests, subtests, cleanup, race detection, coverage, and practical mocking strategies for real-world Go codebases. Use it to write, review, or improve Go test suites with concrete patterns and templates.
How this skill works
The skill inspects testing scenarios and recommends patterns: table-driven tests for input variations, t.Run for subtests, TestMain and t.Cleanup for lifecycle management, and race detection for concurrent code. It suggests when to prefer fakes or small interfaces over heavy mocking, how to structure test files and testdata, and commands to measure coverage and run the race detector.
When to use it
- Writing tests for functions with multiple input/output cases
- Reviewing tests for concurrency or flaky behavior
- Adding or improving integration tests and coverage measurement
- Refactoring tests to reduce duplication and improve readability
- Choosing between fakes, interfaces, and generated mocks
Best practices
- Use table-driven tests with descriptive case names and subtests (t.Run)
- Prefer t.Cleanup for per-test teardown to ensure cleanup runs even on failure
- Run tests with -race for any concurrent code and fix race reports promptly
- Prefer real small fakes or interfaces over complex mocking; only generate mocks when necessary
- Measure coverage with go test -cover and -coverprofile, but focus on meaningful tests not just percentage
Example use cases
- Unit testing an HTTP handler with table-driven cases for valid/invalid requests
- Testing a service with TestMain for shared setup and t.Cleanup for per-test teardown
- Detecting and fixing data races in goroutine-heavy code using go test -race
- Improving test suite organization: testdata/golden files, testutil helpers, and generated mocks when integration is impractical
- Reviewing a pull request to ensure tests are deterministic, cover edge cases, and use clear failure messages
FAQ
Use table-driven tests when you have multiple inputs or variants that follow the same assertion pattern; use single-case tests for complex scenarios that need bespoke setup.
How do I avoid flaky tests with external resources?
Isolate external resources with fakes or in-memory implementations, use t.Cleanup to reliably release resources, and run integration tests separately from unit tests.
When should I generate mocks?
Generate mocks when interacting with heavy external systems or when replacing an implementation is impractical; prefer small hand-written fakes for clarity and fewer maintenance costs.