# BDD practices

## Contents

- [Automation](#automation)
- [Common myths](#common-myths)

## Automation

Automation connects formulated scenarios to the system as tests. The scenario drives the implementation, not the other way around.

### Automating scenarios _after_ implementation is not BDD

It'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.

### Step definitions are glue

Steps 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.

## Common myths

- **Using gocuke means you're doing BDD** — BDD is the three practices, not the tool. gocuke is automation infrastructure.
- **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.
- **Discovery doesn't need a conversation** — even when working solo, the structured thinking of identifying rules, examples, and questions counts. Don't skip it.
- **Scenarios are tests** — they are, but they're also living documentation and specifications. Write them for a reader, not just a test runner.