方法

BDD

行为驱动开发

用业务方能读懂的语言写测试。然后让这些测试通过。

最近审阅: 2026-05-24 审阅人Kevin Riedl wiki ↗

BDD 是把 TDD 的测试语言改写成非工程师也能读的形式。Cucumber 之类工具用 Given/When/Then 格式，让产品经理也能签字。意图是把测试与「它验证的业务行为」对齐，而不是与「当前的实现」对齐。

实际中，它在集成测试与验收测试层级价值最高，因为那层正是工程与产品之间语言屏障真正产生 Bug 的地方。在单元测试层级，BDD 引入的仪式比节省的多。

// FAQ

常见问题

常见问题

TDD 写工程师能读的测试，重点是设计与回归保护。BDD 写非工程师能读的测试（Given / When / Then 格式），重点是产品与工程对业务行为达成共识。两者层级不同，可以同时用；用一个否定另一个是典型误解。
集成测试与验收测试层。那是工程与产品之间「语言屏障」真正产生 Bug 的地方。在单元测试层级用 BDD，引入的仪式（Cucumber 文件、Step 定义、胶水代码）通常比节省的多。
大多数不会。BDD 在大型企业、监管行业（金融、医疗）效果好，那里有 BA 与合规岗位会真的读 Given / When / Then 场景。在小团队，BDD 经常退化成「工程师写给工程师看的伪自然语言」，那时直接回到 TDD 更诚实。