BDD Testing

Write Go tests that describe observable, user-facing behavior rather than implementation mechanics. Ginkgo structures specs as readable sentences; Gomega asserts outcomes. The goal is a suite that survives refactoring because it states what the system does, not how it does it.

Process

READ, UNDERSTAND, RESEARCH, REFLECT before writing any spec.

1. Understand the users and their goals. Identify who calls this code and what outcomes they care about. Specs are written from that vantage point, not from the internals.

2. Discover behaviors, not functions. Walk the subject's public surface and list the behaviors a user would notice: "reports the weight in grams", "rejects an empty title", "retries on transient failure". One behavior → one It.

3. Group behaviors into scenarios. Cluster behaviors under Context/When blocks that name the precondition ("when the book has no author"). The nesting should read as a sentence top-down.

4. Implement with Ginkgo + Gomega. Use the syntax reference for exact APIs: ./references/ginkgo-syntax.md. Start from the template: ./assets/spec-template.go.

5. Run via go test. Specs are standard Go test files — go test ./... works with no extra tooling. The ginkgo CLI adds richer output and parallelism.