BDD 是个方法论
一开始，我认为 BDD = Gherkin + TDD ，即一种自动化测试方法。但有篇文章(BDD 就是测试吗？ )告诉我：这个想法是错的。文章作者认为 BDD 包含测试阶段，但它的核心并不是自动化测试，测试只是个手段，BDD 最重要的部分是各角色（测试，开发，产品等）在讨论需求（协作）阶段用各种方法来明确需求，避免遗漏。
如果从鹅厂的研发模式来看，所谓的“协作”阶段，大约等于我们的需求宣讲。所不同的是我们的需求宣讲过于随意而无定法，输入是产品人员自身的文档（tapd）+ 宣讲过程中的各角色讨论。而 BDD 在这方面有什么不同？BDD 提供了些工具用来进行细致地讨论，并且其输出是可执行的 Gherkin 验收标准。而鹅厂的输出可能是 TAPD + 一些修改意见。表格对比
| 鹅厂 | BDD | |
|---|---|---|
| 输入 | 产品需求 + 会议讨论 | 产品需求 + 会议讨论 + 一些实用的工具 |
| 输出 | 更正后需求 | 更正后的需求 |
| 可自动执行验收标准 |
关于 BDD ，有很多怀疑者，也有不少革新实践者
既然是个方法论，那就必然是个不断演化更新的事物。与 BDD 理念相近的实践有很多，正在读的书
- Specification by Example: How Successful Teams Deliver the Right Software - 2011 Gojko Adzic，
- BDD In Action - 2014(2020年夏会出第二版)
第一本有中文版，第二本的内容简介：
从 BDD 的沟通技能开始，演示如何分析需求以避免开发出不合需求的软件。 并确保你的每一行代码都和项目目标相关。而当建立了这种协作形式后，你将会学习如何使用自动验收标准来指导并监控开发过程，并通过学习 BDD 原则写出更可维护的代码。2020版本会添加 devops 相关的内容。
对一个不断更新的事物，读书看文章，明确知道他的日期非常重要。因为即使作者，也可能几个月后就对之前的想法推翻重来。所以，我们的实践需要独立思考，分析。
实践?
按 BDD 的标准，如果要实施，可能并不是不可行，但这协作阶段，需要让所有开发，测试，产品践行一种新的讨论方式，并同在产出中添加一种新的内容，是个不小的挑战。
关于实践推广，这篇文章给了些反例：10 easy ways to fail at BDD。按他的建议及目前团队的情况，也许可以这样做：