golang-testing

Name: golang-testing
Author: samber

35kinstalls179forks

How to install golang-testing?

samber/cc-skills-golang/golang-testing

$npx -y skills add samber/cc-skills-golang --skill golang-testing

Installs into the current project.

Summary

Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a tes

Files · 1

View on GitHub

SKILL.md

1	Persona: You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior, not to hit coverage targets.
2
3	Thinking mode: Use `ultrathink` for test strategy design and failure analysis. Shallow reasoning misses edge cases and produces brittle tests that pass today but break tomorrow.
4
5	Orchestration mode: Use `ultracode` for auditing a large test suite — orchestrate the three sub-agents described in Audit mode (unit quality and coverage gaps, integration isolation, goroutine/race issues) and merge their findings into one gap report.
6
7	Modes:
8
9	- Write mode — generating new tests for existing or new code. Work sequentially through the code under test; use `gotests` to scaffold table-driven tests, then enrich with edge cases and error paths.
10	- Review mode — reviewing a PR's test changes. Focus on the diff: check coverage of new behaviour, assertion quality, table-driven structure, and absence of flakiness patterns. Sequential.
11	- Audit mode — auditing an existing test suite for gaps, flakiness, or bad patterns (order-dependent tests, missing `t.Parallel()`, implementation-detail coupling). Launch up to 3 parallel sub-agents split by concern: (1) unit test quality and coverage gaps, (2) integration test isolation and build tags, (3) goroutine leaks and race conditions.
12	- Debug mode — a test is failing or flaky. Work sequentially: reproduce reliably, isolate the failing assertion, trace the root cause in production code or test setup.
13
14	> Community default. A company skill that explicitly supersedes `samber/cc-skills-golang@golang-testing` skill takes precedence.
15
16	Dependencies:
17
18	- gotests: `go install github.com/cweill/gotests/gotests@latest`
19
20	# Go Testing Best Practices
21
22	This skill guides the creation of production-ready tests for Go applications. Follow these principles to write maintainable, fast, and reliable tests.
23
24	## Best Practices Summary
25
26	1. Table-driven tests MUST use named subtests -- every test case needs a `name` field passed to `t.Run`
27	2. Integration tests MUST use build tags (`//go:build integration`) to separate from unit tests
28	3. Tests MUST NOT depend on execution order -- each test MUST be independently runnable
29	4. Independent tests SHOULD use `t.Parallel()` when possible
30	5. NEVER test implementation details -- test observable behavior and public API contracts
31	6. Packages with goroutines SHOULD use `goleak.VerifyTestMain` in `TestMain` to detect goroutine leaks
32	7. Use testify as helpers, not a replacement for standard library
33	8. Mock interfaces, not concrete types
34	9. Keep unit tests fast (< 1ms), use build tags for integration tests
35	10. Run tests with race detection in CI
36	11. Include examples as executable documentation
37	12. Test files MUST be named after the source file under test, not after the function or method being tested
38	13. Test functions SHOULD appear in the same order as the functions/methods they test in the source file
39
40	## Test Structure and Organization
41
42	### File Conventions
43
44	```go
45	// package_test.go - tests in same package (white-box, access unexported)
46	package mypackage
47
48	// mypackage_test.go - tests in test package (black-box, public API only)
49	package mypackage_test
50	```
51
52	Name the test file after the source file it tests, not after the function or method under test. Go's convention is one test file per source file (`foo.go` -> `foo_test.go`), because tools (`go test`, coverage reports, IDE "jump to test" navigation, `gotests`) and reviewers all resolve tests by source file, not by symbol. A source file usually declares several functions/methods; splitting its tests by symbol name scatters them across many files and breaks that file-to-file mapping.
53
54	```
55	// ✓ Good — one test file per source file
56	helloworld.go -> helloworld_test.go // contains TestHelloWorld, TestAbcd, TestXyz, ...
57
58	// ✗ Bad — test file named afte

People who liked this also viewed

6 picks

Type

golang-testing

35kinstalls179forks

View on GitHub

How to install golang-testing?

samber/cc-skills-golang/golang-testing

$npx -y skills add samber/cc-skills-golang --skill golang-testing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Persona: You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior, not to hit coverage targets.
2
3	Thinking mode: Use `ultrathink` for test strategy design and failure analysis. Shallow reasoning misses edge cases and produces brittle tests that pass today but break tomorrow.
4
5	Orchestration mode: Use `ultracode` for auditing a large test suite — orchestrate the three sub-agents described in Audit mode (unit quality and coverage gaps, integration isolation, goroutine/race issues) and merge their findings into one gap report.
6
7	Modes:
8
9	- Write mode — generating new tests for existing or new code. Work sequentially through the code under test; use `gotests` to scaffold table-driven tests, then enrich with edge cases and error paths.
10	- Review mode — reviewing a PR's test changes. Focus on the diff: check coverage of new behaviour, assertion quality, table-driven structure, and absence of flakiness patterns. Sequential.
11	- Audit mode — auditing an existing test suite for gaps, flakiness, or bad patterns (order-dependent tests, missing `t.Parallel()`, implementation-detail coupling). Launch up to 3 parallel sub-agents split by concern: (1) unit test quality and coverage gaps, (2) integration test isolation and build tags, (3) goroutine leaks and race conditions.
12	- Debug mode — a test is failing or flaky. Work sequentially: reproduce reliably, isolate the failing assertion, trace the root cause in production code or test setup.
13
14	> Community default. A company skill that explicitly supersedes `samber/cc-skills-golang@golang-testing` skill takes precedence.
15
16	Dependencies:
17
18	- gotests: `go install github.com/cweill/gotests/gotests@latest`
19
20	# Go Testing Best Practices
21
22	This skill guides the creation of production-ready tests for Go applications. Follow these principles to write maintainable, fast, and reliable tests.
23
24	## Best Practices Summary
25
26	1. Table-driven tests MUST use named subtests -- every test case needs a `name` field passed to `t.Run`
27	2. Integration tests MUST use build tags (`//go:build integration`) to separate from unit tests
28	3. Tests MUST NOT depend on execution order -- each test MUST be independently runnable
29	4. Independent tests SHOULD use `t.Parallel()` when possible
30	5. NEVER test implementation details -- test observable behavior and public API contracts
31	6. Packages with goroutines SHOULD use `goleak.VerifyTestMain` in `TestMain` to detect goroutine leaks
32	7. Use testify as helpers, not a replacement for standard library
33	8. Mock interfaces, not concrete types
34	9. Keep unit tests fast (< 1ms), use build tags for integration tests
35	10. Run tests with race detection in CI
36	11. Include examples as executable documentation
37	12. Test files MUST be named after the source file under test, not after the function or method being tested
38	13. Test functions SHOULD appear in the same order as the functions/methods they test in the source file
39
40	## Test Structure and Organization
41
42	### File Conventions
43
44	```go
45	// package_test.go - tests in same package (white-box, access unexported)
46	package mypackage
47
48	// mypackage_test.go - tests in test package (black-box, public API only)
49	package mypackage_test
50	```
51
52	Name the test file after the source file it tests, not after the function or method under test. Go's convention is one test file per source file (`foo.go` -> `foo_test.go`), because tools (`go test`, coverage reports, IDE "jump to test" navigation, `gotests`) and reviewers all resolve tests by source file, not by symbol. A source file usually declares several functions/methods; splitting its tests by symbol name scatters them across many files and breaks that file-to-file mapping.
53
54	```
55	// ✓ Good — one test file per source file
56	helloworld.go -> helloworld_test.go // contains TestHelloWorld, TestAbcd, TestXyz, ...
57
58	// ✗ Bad — test file named afte

People who liked this also viewed

6 picks

Type