| name | bdd-with-approvals |
| description | Scannable BDD tests written in domain language. Use when doing BDD. |
BDD with Approval Tests
The Problem
Specifications live in documents. They drift from reality because nothing enforces them.
Tests verify implementation. Written after code, they document what IS, not what SHOULD BE. They're noisy. You can't glance at them and quickly validate correctness.
You need an artifact that:
- Captures expected behavior before code exists
- Stays in sync because it's executable
- A human can validate at a glance
Executable Specifications
The fixture file IS that artifact. Write it BEFORE implementation.
Think through scenarios by creating approval files. Describe expected behavior in domain language. Implementation is driven by making these specs pass. Specs stay executable, never go stale.
A human looks at the fixture and immediately sees: correct or not. No translation between "spec" and "test". They're the same artifact.
For the approval testing technique itself (verify, scrubbers, combinations), see /approval-tests. For nulled infrastructure in system tests, see /nullables.
Approved Fixtures
Test files combining input and expected output in a format designed for human validation.
## Input
(context, parameters, initial state)
## Output
(expected results, side effects, final state)
Test runner reads fixtures, executes code, compares output. Adding test cases = adding files, not code.
Design the format for YOUR domain:
- Grid/spatial problems → ASCII art
- Transformations → before/after
- Workflows → step sequences with results
- API interactions → request/response pairs
See references/approved-fixtures.md for examples.
