BDD practices
Contents
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.