BDD

2026-03-261 引用
CSMethodology
  • S：在学习和实践“Behavior-Driven Development”时，需要建立统一的概念和问题边界。
  • C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
  • Q：“Behavior-Driven Development”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
  • A：本文围绕“Behavior-Driven Development”整理核心概念、关键机制和工程实践，并明确其适用边界。

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 教学中的绝大多数困惑。

评论