1 · 读书笔记：BDD-in-action#

BDD in Action, Second Edition

https://book.douban.com/subject/34960760/

一句话补充如下点：

• 是什么（What）— 理论/原则，建立认知模型
• 为什么（Why）— 背后的动机、约束与权衡
• 怎么做（How）— 技巧 + 实践 + 边界（该做与不该做）

1.1 · 核心观点：

BDD 不只是一种测试技术，而是一种协作式软件设计方法：通过结构化对话（业务目标→Feature→Example→可执行规格），让所有人（开发、测试、业务方）对”软件该做什么”达成共识，再将共识转化为可自动验证的活文档。

• What: BDD = 用具体示例（Example）描述期望行为，形成可执行规格（Executable Specification），既是需求文档又是验收测试。
• Why: 约一半的软件项目未能交付真正的需求。根因不是技术，而是沟通——需求理解不一致、假设未被暴露。BDD 通过”先对齐行为，再写代码”来降低这个风险。
• How: 自顶向下的三阶段循环：
  1. Speculate（发现）：从业务目标出发，用 Feature Injection / Impact Mapping 找出高价值 Feature。
  2. Illustrate（具象化）：用 Example Mapping 等协作会议，将 Feature 拆解为具体示例，暴露边界与假设。
  3. Automate（自动化）：示例 → Given/When/Then 格式 → 自动化验收测试 → 活文档（Living Documentation）。

1.2 · 启发点（关键洞察）：

1. “Outside-In”开发：从业务行为（验收测试）向内驱动到单元测试，确保每一行代码都服务于已确认的行为，而非凭空设计。
2. Deliberate Discovery（刻意发现）：项目最大的风险是”不知道自己不知道什么”。BDD 的协作对话本质上是一个结构化的”发现无知”过程。
3. Real Options（真实选项）：推迟决策直到获得足够信息——选项有价值、选项会过期、了解了原因再行动。避免在信息不足时过早承诺方案。
4. 分离 What 与 How：验收测试三层架构——业务规则层（Scenario 描述）/ 业务流程层（Step 实现）/ 技术层（UI/API 交互）。Scenario 应稳定不变，实现细节可随时替换。
5. 活文档（Living Documentation）：可执行规格自动产出的文档始终与代码同步，消灭”文档过期”问题，也让非技术人员能随时查看系统当前行为。
6. BDD 建立在 TDD 之上：BDD 不替代 TDD，而是在更高层次（行为/需求层）补充 TDD，两者形成”外→内”的双层驱动。

1.3 · 行动：

1. 在需求讨论中引入 Example Mapping 会议：用四色卡片（规则-示例-问题-故事）快速对齐理解，暴露假设。
2. 尝试用 Given/When/Then 格式书写关键业务场景的验收标准，即使暂不自动化，也能改善沟通精度。
3. 实践 Outside-In 开发流程：先写一个失败的验收测试描述行为，再向内补充单元测试和实现代码。

1.4 · 金句：

1. “BDD is about conversations, not testing.” —— BDD 的核心在于对话，而非测试本身。
2. “The biggest risk on most projects is not that we will build it wrong, but that we will build the wrong thing.” —— 最大风险不是做错，而是做了不该做的东西。
3. “Examples are the unit currency of BDD.” —— 示例是 BDD 的基本货币。