1# Go testing
2
3Read [../testing.md](../testing.md), [baseline.md](baseline.md), and
4[mise.md](mise.md) before applying these Go testing specifics.
5
6## Go defaults
7
8- Use `go test -v -race -count=5 -p=3 -timeout=5m ./...` in development tasks.
9- Set `CGO_ENABLED=1` for race-enabled test tasks. Builds and releases can still
10 use `CGO_ENABLED=0` when dependencies allow it.
11- Table-driven tests are the default for pure functions and parsers.
12- Use `t.Parallel()` when the test does not mutate env, package globals,
13 filesystem globals, terminal probes, or shared services.
14- Copy loop variables before parallel subtests when needed.
15- Use `t.TempDir()` and `t.Setenv()` for isolation.
16- Restore package globals with `t.Cleanup()`.
17- Use `httptest` for HTTP clients/servers.
18- Prefer `go-cmp` for structured diffs.
19
20## Behaviour and BDD
21
22When behaviour is still being discovered, use the BDD discovery skill first if
23available.
24
25Do not add gocuke implicitly. Ask whether this project wants gocuke/BDD
26automation. If yes, load `testing-with-gocuke-and-gherkin` after behaviour is
27formulated. If no, use ordinary Go tests.
28
29Good fits for gocuke:
30
31- config merge/precedence rules
32- interactive flow rules
33- non-interactive CLI behaviour
34- lifecycle rules with many examples
35
36Keep step definitions grouped by domain concept, not by feature-file name. Let
37gocuke print missing step signatures instead of hand-guessing them.
38
39## Property tests
40
41Use `pgregory.net/rapid` around:
42
43- parsers and serializers
44- path/config expansion
45- state machines
46- merge logic
47- sorting/ranking invariants
48
49Keep properties small and name the invariant clearly.
50
51## TUI tests
52
53Load `golang-tui` for Bubble Tea harnesses, snapshots, and terminal-specific
54test patterns. Keep the regular race-enabled Go test task from [mise.md](mise.md).
55Add snapshot/golden update tasks only when the project actually has snapshot
56tests.
57
58## Wails/frontend tests
59
60Backend logic should remain testable without Wails. Frontend tests are useful
61for non-trivial state reducers, parsing, and rendering helpers; do not require a
62browser stack for simple static views unless the project already has one.