核心要点

  • 从行为与用户故事出发，关注系统「做什么」而非「怎么实现」

  • 用 Given-When-Then（Gherkin）自然语言描述可执行的场景

  • 促进开发、测试、产品三方就业务语义达成一致

  • 与 TDD 互补：BDD 偏验收/外部行为，TDD 偏单元/内部实现

标准回答

BDD 是什么

BDD（Behavior-Driven Development）从「用户行为/业务价值」出发，用接近自然语言的方式描述系统应有的行为，让非技术角色也能参与并验证需求。

Gherkin 场景

gherkin
Scenario: 余额充足时可以下单
  Given 用户账户余额为 100 元
  When  用户购买一件 60 元的商品
  Then  下单成功且余额变为 40 元

与 TDD 的区别

  • 出发点：TDD 从「待实现的代码单元」出发；BDD 从「用户故事/业务行为」出发。
  • 抽象层次：BDD 偏外部、验收级，描述「做什么」；TDD 偏内部、单元级，关注「怎么实现对」。
  • 语言与受众：BDD 用 Given-When-Then 让产品/测试可读；TDD 用断言代码，主要面向开发者。

两者并不冲突：常用 BDD 描述验收场景对齐业务，再用 TDD 在内部小步实现，BDD 是 TDD 的一种「外层、面向业务」的延伸。

常见误区

⚠️ 常见踩坑

BDD 不只是「换种语法写测试」；其价值在于用统一语言对齐业务理解，若产品/测试不参与，只剩 Gherkin 外壳便失去意义。

追问

追问 1：Given-When-Then 各代表什么？

Given 描述前置条件/初始上下文；When 描述触发的关键行为或事件；Then 描述期望的可观察结果。一个场景应聚焦单一行为，避免一个 Then 里堆砌多个无关断言。

追问 2：BDD 适合所有项目吗？

不一定。它在业务规则复杂、需跨角色对齐需求的场景收益最大；对纯技术性、无明显业务语义的底层模块，维护 Gherkin 反而增加成本，直接用 TDD 更合适。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。

📖 术语表

🎯 相关面试题