1# Testing
 2
 3Test depth should match risk. Tooling changes need command verification; domain
 4behaviour needs tests; broad shared behaviour deserves BDD or property coverage.
 5
 6## Defaults
 7
 8- Prefer fast, isolated automated tests over smoke testing.
 9- Follow red/green TDD for behaviour changes when practical: write or update the
10  failing test first, then implement the smallest slice that makes it green.
11- Do not smoke test unless asked. If smoke testing reveals a gap, add or improve
12  automated tests so the same issue is caught in the future.
13- Use temp directories, scoped environment overrides, and cleanup hooks for
14  isolation.
15- Restore package/module globals after tests that mutate them.
16- Add integration tests around real protocol, filesystem, database, or process
17  boundaries when mocks would hide the risk.
18
19## Behaviour and BDD
20
21When behaviour is still being discovered, use the BDD discovery skill first if
22available. Do not add a BDD runner implicitly; ask whether the project wants BDD
23automation after the behaviour is formulated.
24
25Good fits for BDD:
26
27- config merge/precedence rules
28- interactive flow rules
29- non-interactive CLI behaviour
30- lifecycle rules with many examples
31
32## Property tests
33
34Use property tests around:
35
36- parsers and serializers
37- path/config expansion
38- state machines
39- merge logic
40- sorting/ranking invariants
41
42Keep properties small and name the invariant clearly.
43
44## Go path
45
46For Go tests, BDD automation, race settings, TUI tests, or Wails/frontend split
47checks, read [golang/index.md](golang/index.md) first and follow its testing
48chain. The Go path covers gocuke, rapid, go-cmp, race-enabled test tasks, and
49Charm/Wails test posture.