Daniel Horn: BDD is Not a Testing Approach - How to Overuse BDD to Slow Down Your Delivery
summary
Argument: BDD is a development practice, not a QA shortcut; when teams push Gherkin/Cucumber feature files downstream as UI acceptance tests they add overhead, brittle Selenium suites and maintenance (rewriting ~100 scenarios when a button name changes). Treat feature files as feature files in Git tied to user stories, implement behaviors low in the stack and run behaviors at unit layer under CI (Jenkins), report with Xray/Allure or Confluence, and avoid UI-first BDD unless starting small or on a greenfield project.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:05What is BDD
- 4:40BDD origins
- 6:49BDD pitfalls
- 9:18Organizational silos
- 13:01BDD as code
- 16:56Maintenance hell
- 18:25BDD in testing
- 20:13BDD across layers
- 22:49BDD process limits
- 26:30BDD adoption tips
- 27:39Q&A
- 28:46Publishing BDD docs
- 30:53BDD living docs
- 32:43Can BDD be abandoned
- 34:06Summary
related talks
49mBDD Is Not Test Automation
09m"Effective ways of using BDD concept for Testing"
08m"BDD: NOT The Given-When-Then Thing"
48mBDD - It’s More Than Acceptance Tests
24mFighting against technical debt with BDD, DevOps and Sustainability
51mDoes BDD Adds Additional Architectural Limitations on Solutions for Testing?
48mMake Your Life Simple and Carefree with BDD
43mBetter Bullshit-Driven Development