# 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](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.