1# BDD practices
 2
 3## Contents
 4
 5- [Automation](#automation)
 6- [Common myths](#common-myths)
 7
 8## Automation
 9
10Automation connects formulated scenarios to the system as tests. The scenario drives the implementation, not the other way around.
11
12### Automating scenarios _after_ implementation is not BDD
13
14It's a perfectly reasonable way to do test automation, but the value of BDD is that failing tests _guide_ the implementation. Writing tests after the fact loses that feedback loop.
15
16### Step definitions are glue
17
18Steps connect Gherkin to your system. They should be thin — call into the real code, set up fixtures, make assertions. Don't put business logic in step definitions.
19
20## Common myths
21
22- **Using gocuke means you're doing BDD** — BDD is the three practices, not the tool. gocuke is automation infrastructure.
23- **You can pick practices in any order** — Discovery → Formulation → Automation. Having conversations is more important than capturing them, which is more important than automating them.
24- **Discovery doesn't need a conversation** — even when working solo, the structured thinking of identifying rules, examples, and questions counts. Don't skip it.
25- **Scenarios are tests** — they are, but they're also living documentation and specifications. Write them for a reader, not just a test runner.