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