1 · BDD#

S 什么场景 C 什么冲突 Q 什么问题 A 回答问题

https://dannorth.net/blog/introducing-bdd/

Dan North（BDD 提出者）2006 年的奠基文章，讲述了 BDD 如何从 TDD 的痛点中演化而来。

S 场景：作者在教授和实践 TDD 时，反复遇到相同的困惑——从哪里开始写测试？测什么不测什么？测试该怎么命名？测试失败了意味着什么？

C 冲突：“test”这个词本身就是误导源。开发者纠结于”测试覆盖率”而忽视了行为描述；新手害怕删测试，认为删除会降低质量；测试方法命名随意导致失败时无法定位意图。

Q 问题：能否换一种表达方式，让 TDD 直达本质、避开所有陷阱？

A 回答：用 “行为（behaviour）“替代”测试（test）“，一切迎刃而解——

1. 命名即文档：测试方法名写成句子，以 should 开头（“类应该做某事”），自动生成可读文档（agiledox 工具）。
2. 聚焦当前类：should 模板约束你只描述当前类的行为，发现描述不了就说明职责该拆分到新类。
3. 失败时三问：测试失败 →（a）引入了 bug？修复。（b）行为迁移了？移动测试。（c）前提变了？删除测试。
4. 从价值出发：“系统还不能做的下一件最重要的事是什么？“——回答了 TDD 的”从哪开始”。
5. 需求也是行为：同样的思维上升到分析层——Story 模板（As a / I want / So that）+ 验收标准用 Given/When/Then 场景表达。
6. 场景片段可执行可复用：每个 Given/When/Then 映射为代码类，跨场景复用，最终从 mock 演进为端到端功能测试。

核心洞察：BDD 的本质不是新工具，而是语言的转变——从”测试”到”行为”，从”验证代码”到”描述系统应该做什么”，这一词汇变化消除了 TDD 教学中的绝大多数困惑。