BDD

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

它在哪里真正有回报，举个实际例子：一个保险产品有一条规则，少于 30 天、且有有效保单的理赔自动通过。写成一个 Gherkin 场景（「Given 一份生效 30 天的保单，When 在保障窗口内提交理赔，Then 它自动通过」），产品负责人和合规审核人都能读它、确认它匹配真实规则，并在它发布之前抓住那个差一错误。那种共享语言的核对，正是 BDD 的全部价值，而它住在验收和集成层，那里正是「产品想要的」和「工程造出来的」之间的鸿沟、Bug 诞生的地方。

还有一项团队很晚才发现的维护成本。Gherkin 场景坐落在一层「Step 定义」之上，那是把每一行通俗英语映射到实际测试动作的胶水代码。那层胶水是真实的软件，必须随产品变化保持同步，而一个 Step 定义草率的大型 BDD 套件会变成它自己的维护负担，跑得慢、改起来脆。它的好处（一位利益相关者能读并签字确认行为）只有在确实有利益相关者去读时才抵得上那份开销。如果 Gherkin 由工程师写、由工程师读、从没被别人看过，你就是在为一个没有观众的翻译层付费。

诚实的取舍与常见错误：BDD 不是 TDD 的替代品，它是叠在上面的一层，而把它到处用就是那个错误。为一个琐碎函数写「Given 两个数，When 我把它们相加，Then 我得到和」是没有任何业务利益相关者会读的仪式。把 Gherkin 留给那些非工程师确实需要签字的测试，那条线以下用朴素的单元测试。像所有这些实践一样，BDD 是一段清醒的 SDLC 里的一个阶段，是为一个真实的沟通问题准备的工具，而不是一个为自身而采纳的流程。