Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/muratmirgun/gophersnpx agentmods add skills/muratmirgun/gophers/go-testingWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/muratmirgun/gophers/go-testing)<a href="https://agentmods.dev/skills/muratmirgun/gophers/go-testing"><img src="https://agentmods.dev/badge/skills/muratmirgun/gophers/go-testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/muratmirgun/gophers/go-testing"><img src="https://agentmods.dev/badge/skills/muratmirgun/gophers/go-testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00070 | $0.02524 |
| Opus 5.5 | $0.00028 | $0.01010 |
| Sonnet 5.5 | $0.00014 | $0.00505 |
| Haiku 4.5 | $0.00007 | $0.00252 |
Grade A, and why
go-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 200 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Go Testing
Tests are executable specifications. Their job is to fail usefully when behaviour regresses — and to keep failing in the same way until the bug is fixed. Tests that are passing-or-flaky teach the team to ignore them, which is worse than no test at all.
Core Rules
- Failures must be diagnosable from the log alone. Every
t.Errorfincludes the function under test, the inputs, what we got, and what we wanted, in that order. - No assertion libraries by default. Use the standard
t.Errorf/t.Fatalfplusgo-cmpfor structural comparison.testifyis acceptable when adopted consistently — pick one and stick with it. - Test observable behaviour, not implementation details. If a refactor that preserves behaviour breaks the test, the test was wrong.
- Each test runs independently. No execution-order dependencies, no shared global state without
t.Cleanup. t.Parallel()whenever the test is safe to run in parallel. Most are.t.Helper()is the first line of any helper function that callst.Errorf/t.Fatalf. Reservet.Fatalfor "next line is meaningless without this value"; everything else usest.Error. Never callt.Fatal/t.FailNowfrom a non-test goroutine — send the failure back via channel.
"Useful Failures" Format
The failure message is the test's user interface. The canonical shape:
FunctionUnderTest(input) = got, want want
// Good
t.Errorf("Add(2, 3) = %d, want %d", got, 5)
// Bad — no function, no inputs, reversed
t.Errorf("expected %d but got %d", 5, got)
Always print got before want. With cmp.Diff(want, got), the diff shows (-want +got) — echo that direction in your message.
"No Asserts" Philosophy
Standard-library testing with if + t.Errorf reads as plain Go and produces messages you control. Assertion libraries shorten call sites but trade away message quality and reorder the got/want convention.
- Default —
if got != want { t.Errorf("...") }pluscmp.Difffor structs, slices, maps, protos. - Permitted —
testifyif the team agrees andtestifylintis enabled.requireonly when continuing is meaningless. - Avoid — mixing styles within the same package.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 200 lines · 70 tokens per session scan A d9fcac807f26
go-testing is a skill published in the GitHub repository muratmirgun/gophers (9 stars, last pushed 2mo ago), licensed MIT. It adds 70 tokens to every session and 2,524 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
encore-go-testing
Write or run automated tests for Encore Go code with encore test and the standard library testing package. Covers isolated per-test databases, calling handlers directly, and testing.T patterns.
go-testing-mistakes
Guides the agent to avoid common Go testing mistakes when writing or reviewing test code. Covers test categorization (build tags, env vars, short mode), race detection, test execution modes (parallel, shuffle), table-driven tests, avoiding sleeps in tests, handling the time API deterministically, using httptest/iotest…
go-testing-quality
Use when writing or reviewing Go tests, adding coverage, benchmarking, or profiling a Go program. Not for CI/lint wiring (go-tooling-security) or non-Go tests.
test-go
Write, review, and improve Go test code for this project. Use whenever generating, reviewing, or modifying Go tests - including when invoked by the Tester agent, the /test prompt, or any test-related request. Covers table-driven tests, subtests, t.Parallel(), test helpers with t.Helper(), error assertions via…
go-test
When the user wants to design, implement, debug, or optimize Go tests using the standard testing package, testify, and related Go ecosystem libraries. Use when the user mentions "go test," "table-driven tests," "t.Run," "subtests," "testify," "require / assert," "go test -race," "go test -bench," "go test -fuzz,"…
golang-stretchr-testify
Comprehensive guide to stretchr/testify for Golang testing. Covers assert, require, mock, and suite packages in depth. Use when writing tests with testify, creating mocks, setting up test suites, or choosing between assert and require. Covers testify assertions, mock expectations, argument matchers, call verification…