Testing

Test depth should match risk. Tooling changes need command verification; domain behaviour needs tests; broad shared behaviour deserves BDD or property coverage.

Defaults

• Prefer fast, isolated automated tests over smoke testing.
• Follow red/green TDD for behaviour changes when practical: write or update the failing test first, then implement the smallest slice that makes it green.
• Do not smoke test unless asked. If smoke testing reveals a gap, add or improve automated tests so the same issue is caught in the future.
• Use temp directories, scoped environment overrides, and cleanup hooks for isolation.
• Restore package/module globals after tests that mutate them.
• Add integration tests around real protocol, filesystem, database, or process boundaries when mocks would hide the risk.

Behaviour and BDD

When behaviour is still being discovered, use the BDD discovery skill first if available. Do not add a BDD runner implicitly; ask whether the project wants BDD automation after the behaviour is formulated.

Good fits for BDD:

• config merge/precedence rules
• interactive flow rules
• non-interactive CLI behaviour
• lifecycle rules with many examples

Property tests

Use property tests around:

• parsers and serializers
• path/config expansion
• state machines
• merge logic
• sorting/ranking invariants

Keep properties small and name the invariant clearly.

Go path

For Go tests, BDD automation, race settings, TUI tests, or Wails/frontend split checks, read golang/index.md first and follow its testing chain. The Go path covers gocuke, rapid, go-cmp, race-enabled test tasks, and Charm/Wails test posture.