diff options
| author | Paul Buetow <paul@buetow.org> | 2026-06-19 21:50:50 +0300 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2026-06-19 21:50:50 +0300 |
| commit | 23e6a94a83f2482372b961d6e6041d512f66aa4a (patch) | |
| tree | 9ca98f2746f46cc0f29fb5aee02fff42c611e14e | |
| parent | 2affccf8438736073c9dac1303483f68be1ca7f3 (diff) | |
go-best-practices: document slow/timeout-exceeding test suites
Add a section on handling test suites that work but exceed the
go-test/mage/command timeout (e.g. mage integrationTest > 30m):
which focused subset to run (-short/-run/build tags, touched
packages), how to annotate that the full suite was intentionally
skipped, and the acceptance implications (focused subset is not
full verification). Cross-references the 8q0 missing-toolchain
section rather than restating it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| -rw-r--r-- | prompts/skills/go-best-practices/SKILL.md | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/prompts/skills/go-best-practices/SKILL.md b/prompts/skills/go-best-practices/SKILL.md index 4326794..e0e384b 100644 --- a/prompts/skills/go-best-practices/SKILL.md +++ b/prompts/skills/go-best-practices/SKILL.md @@ -74,6 +74,14 @@ Before claiming any verification, confirm the local toolchain can actually build * **Annotate the blocker explicitly:** Record what is missing and the impact with `ask annotate <id> "<note>"`—name the missing header/tool, what you verified, and what you could not. * **Never claim full verification when it did not run:** State precisely what was and was not verified (e.g. "vet + gofmt clean; `./internal/bpf` not built—`bpf/bpf.h` missing; eBPF tests not run"). Do not imply a green build or passing tests that never executed. +### Long-running / timeout-exceeding test suites + +Distinct from a *missing* toolchain (see "Environment preflight and verification honesty"): here the toolchain works, but the full suite is too SLOW to finish within the go-test / mage / command timeout (e.g. `mage integrationTest` runs > 30m). Run a focused subset rather than nothing, and be explicit that you did so. + +* **Run a representative subset within the timeout:** Scope to the package(s) the change touches and skip the slow target—e.g. `go test ./internal/foo/... -run <Pattern> -short`. Prefer `-short` (have slow tests honor `testing.Short()`), build tags, or `-run` to exclude expensive integration/E2E tests; run the unit subset when the full integration suite can't complete. +* **Annotate the intentional skip:** Record with `ask annotate <id> "<note>"` that the full suite was *intentionally* skipped, why (exceeds timeout, not a failure), which subset ran, and the result—e.g. "integrationTest skipped (>30m, timeout); ran `go test ./internal/foo/... -short` → pass". +* **Acceptance implications:** A focused subset is NOT full verification. Be explicit about residual risk—untested integration paths, packages not touched—so the reviewer/orchestrator can decide whether to accept or run the full suite out-of-band. As in 8q0, never imply the full suite passed when it never ran. + ### Build system Use Mage (Magefile.go) for build, install and test targets (and deinstall/uninstall when needed). |