go-testing-quality

Name: go-testing-quality
Author: fusengine

21stars3forks

How to install go-testing-quality?

fusengine/agents/go-testing-quality

$npx -y skills add fusengine/agents --skill go-testing-quality

Installs into the current project.

Summary

Write idiomatic Go tests and measure quality — table-driven tests, subtests with t.Run, testify assertions/mocks, native fuzzing, benchmarks, the race detector, coverage, and pprof/PGO profiling. Use when writing or reviewing Go tests, adding coverage, benchmarking, or profiling

Files · 1

View on GitHub

SKILL.md

1	# Go Testing & Quality
2
3	Idiomatic, 2026-current testing and quality practices for Go, built on the standard
4	`testing` package with `testify` where it adds clarity.
5
6	Use when:
7	- Writing unit tests for Go code (table-driven, subtests)
8	- Adding assertions or mocks with `testify` (`assert` / `require` / `mock`)
9	- Writing fuzz tests, benchmarks, or example tests
10	- Measuring coverage (`go test -cover`) or chasing race conditions (`-race`)
11	- Profiling / optimizing with pprof or setting up PGO
12	- Reviewing an existing Go test suite for quality gaps
13
14	Do NOT use for:
15	- Project layout, routing, DB wiring, DI — use `go-architecture`
16	- SOLID line-limit / interface enforcement — use `fuse-solid:solid-go`
17	- Non-Go test suites (Pest, Vitest, Jest, cargo test) — use the matching expert
18	- Security scanning / CVE audit — use `fuse-security`
19
20	---
21
22	## Decision Map
23
24	\| Goal \| Load \|
25	\|------\|------\|
26	\| Write the standard Go test (table-driven + subtests) \| [table-driven.md](references/table-driven.md) \|
27	\| Assertions and mocks with testify \| [testify-mocks.md](references/testify-mocks.md) \|
28	\| Fuzzing, benchmarks, example tests \| [fuzzing-benchmarks.md](references/fuzzing-benchmarks.md) \|
29	\| Coverage, race detector, pprof, PGO \| [coverage-profiling.md](references/coverage-profiling.md) \|
30	\| A complete, runnable test file to copy \| [templates/table-test.md](references/templates/table-test.md) \|
31
32	---
33
34	## Core Practices (2026)
35
36	1. Table-driven tests are the idiom. Define a slice of cases, loop, and run
37	each as a subtest with `t.Run(tc.name, …)` for isolation and readable output.
38	2. `testify` is the de-facto assertion/mock standard. `assert` for soft checks,
39	`require` to abort on failure, `mock` for hand-written mocks, `suite` for
40	setup/teardown groups. It is maintained at v1 (no breaking v2).
41	Source: https://pkg.go.dev/github.com/stretchr/testify
42	3. Fuzzing is native since Go 1.18 (`func FuzzXxx(f *testing.F)`), and finds
43	edge cases table tests miss.
44	4. Always run `-race` in CI. The race detector catches data races that are
45	otherwise nondeterministic and unreproducible.
46	5. Measure before optimizing. Benchmarks (`go test -bench`) + pprof profiles
47	guide real changes; PGO feeds a production profile back into the compiler.
48
49	---
50
51	## Workflow
52
53	1. Explore the code under test and existing test conventions first.
54	2. Write table-driven tests as the default shape ([table-driven.md](references/table-driven.md)).
55	3. Add testify assertions/mocks where they improve readability, not reflexively.
56	4. Run `go test ./... -race -cover` and inspect gaps.
57	5. Fuzz / benchmark hotspots and parsers ([fuzzing-benchmarks.md](references/fuzzing-benchmarks.md)).
58	6. Profile only after a benchmark proves a hotspot ([coverage-profiling.md](references/coverage-profiling.md)).
59	7. Validate with sniper after changes.
60
61	---
62
63	## Boundaries
64
65	Overlaps with `github.com/samber/cc-skills-golang` (community Go skills) — this
66	skill owns testing and quality tooling; architecture/structure lives in
67	`go-architecture`. Cross-referenced for boundaries only, not copied.

People who liked this also viewed

6 picks

Type

go-testing-quality

21stars3forks

View on GitHub

How to install go-testing-quality?

fusengine/agents/go-testing-quality

$npx -y skills add fusengine/agents --skill go-testing-quality

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Go Testing & Quality
2
3	Idiomatic, 2026-current testing and quality practices for Go, built on the standard
4	`testing` package with `testify` where it adds clarity.
5
6	Use when:
7	- Writing unit tests for Go code (table-driven, subtests)
8	- Adding assertions or mocks with `testify` (`assert` / `require` / `mock`)
9	- Writing fuzz tests, benchmarks, or example tests
10	- Measuring coverage (`go test -cover`) or chasing race conditions (`-race`)
11	- Profiling / optimizing with pprof or setting up PGO
12	- Reviewing an existing Go test suite for quality gaps
13
14	Do NOT use for:
15	- Project layout, routing, DB wiring, DI — use `go-architecture`
16	- SOLID line-limit / interface enforcement — use `fuse-solid:solid-go`
17	- Non-Go test suites (Pest, Vitest, Jest, cargo test) — use the matching expert
18	- Security scanning / CVE audit — use `fuse-security`
19
20	---
21
22	## Decision Map
23
24	\| Goal \| Load \|
25	\|------\|------\|
26	\| Write the standard Go test (table-driven + subtests) \| [table-driven.md](references/table-driven.md) \|
27	\| Assertions and mocks with testify \| [testify-mocks.md](references/testify-mocks.md) \|
28	\| Fuzzing, benchmarks, example tests \| [fuzzing-benchmarks.md](references/fuzzing-benchmarks.md) \|
29	\| Coverage, race detector, pprof, PGO \| [coverage-profiling.md](references/coverage-profiling.md) \|
30	\| A complete, runnable test file to copy \| [templates/table-test.md](references/templates/table-test.md) \|
31
32	---
33
34	## Core Practices (2026)
35
36	1. Table-driven tests are the idiom. Define a slice of cases, loop, and run
37	each as a subtest with `t.Run(tc.name, …)` for isolation and readable output.
38	2. `testify` is the de-facto assertion/mock standard. `assert` for soft checks,
39	`require` to abort on failure, `mock` for hand-written mocks, `suite` for
40	setup/teardown groups. It is maintained at v1 (no breaking v2).
41	Source: https://pkg.go.dev/github.com/stretchr/testify
42	3. Fuzzing is native since Go 1.18 (`func FuzzXxx(f *testing.F)`), and finds
43	edge cases table tests miss.
44	4. Always run `-race` in CI. The race detector catches data races that are
45	otherwise nondeterministic and unreproducible.
46	5. Measure before optimizing. Benchmarks (`go test -bench`) + pprof profiles
47	guide real changes; PGO feeds a production profile back into the compiler.
48
49	---
50
51	## Workflow
52
53	1. Explore the code under test and existing test conventions first.
54	2. Write table-driven tests as the default shape ([table-driven.md](references/table-driven.md)).
55	3. Add testify assertions/mocks where they improve readability, not reflexively.
56	4. Run `go test ./... -race -cover` and inspect gaps.
57	5. Fuzz / benchmark hotspots and parsers ([fuzzing-benchmarks.md](references/fuzzing-benchmarks.md)).
58	6. Profile only after a benchmark proves a hotspot ([coverage-profiling.md](references/coverage-profiling.md)).
59	7. Validate with sniper after changes.
60
61	---
62
63	## Boundaries
64
65	Overlaps with `github.com/samber/cc-skills-golang` (community Go skills) — this
66	skill owns testing and quality tooling; architecture/structure lives in
67	`go-architecture`. Cross-referenced for boundaries only, not copied.

People who liked this also viewed

6 picks

Type