观看本文后，你将能够定义行为驱动开发（BDD），解释BDD如何推动满足客户期望，并描述BDD的主要优势。
行为驱动开发（BDD），顾名思义，它从外向内聚焦于系统的行为。这与测试驱动开发不同，测试驱动开发关注系统内部的工作细节。
BDD非常适合用于集成测试，以查看所有组件是否协同工作。它促使你"从外向内"思考。换句话说，你只实现那些对业务成果有最直接贡献的行为。
BDD的优势之一在于，它用一种统一的表示法来描述行为，领域专家、测试人员、开发人员和客户都能直接理解。这改善了团队间的沟通。
如果将BDD与TDD进行比较，我们会发现它们的切入点正好相反。BDD从外向内描述系统行为，就像系统的使用者那样看待系统；而TDD从内向外测试系统功能，它确保每个组件正常工作，而BDD则在更高层面上确保所有组件协同工作。
换句话说，BDD确保你构建的东西是正确的，即具备正确的功能和行为；TDD确保你正确地构建东西，即每个功能都能完成其预期任务。
BDD的工作流程是这样的：开发人员、测试人员和客户首先探索问题领域，并通过协作给出具体示例，描述他们期望的行为。他们使用一种名为Gherkin的语言记录这些行为，这是一种自然语言表示法，我稍后会详细介绍。
接下来，团队使用BDD工具（如Python的Behave、Java的jBehave或Ruby的Cucumber）将这些示例作为自动化验收测试来运行。在团队解决问题的过程中，BDD工具会告知他们哪些示例已实现并能正常工作，同时提醒他们哪些还未完成。
不知不觉中，你就拥有了一份既是软件规格说明又是测试用例的文档。
Gherkin是一种易读的自然语言语法，采用常见的"Given...When...Then..."结构。技术人员和非技术人员都很容易理解。如果你想知道Gherkin这个名字的由来，最初使用这种语法的工具叫Cucumber（黄瓜），而Gherkin指腌黄瓜，腌黄瓜是用黄瓜制作的。工具常常会起这样有趣的名字。
下面介绍一下Gherkin语法的使用方法。
- Given some context（给定某种上下文）：这是在为测试设置上下文或前置条件，目的是在用户（或外部系统）开始与系统交互之前，将系统置于已知状态。
- When some event happens（当某个事件发生时）：这是描述正在执行的主要操作，它将系统从初始状态转变为新的可观察状态。
- Then some testable outcome or behavior is validated（然后验证某个可测试的结果或行为）："Then"用于观察结果，这些观察结果应与功能的业务价值或益处相关。"And"用于延续条件，例如"Given this And that...""Then this And that..."等等，它为你提供了一种自然的方式来添加更多的上下文、事件或结果。
让我们来看一个零售店的例子。这些被称为功能文件或功能文档，每个文档对应一个功能，并且有许多场景来描述这个功能。在这个例子中只有一个场景，但为了涵盖所有可能的情况，肯定会有更多场景。
这个功能叫"退货入库"，它描述了客户退回所购商品时系统的行为。注意，它使用了"As a（作为）""I need（我需要）""So that（以便）"的语法，我们在编写用户故事时会用到这种语法。你可以把它看作是带有验收标准的用户故事，其中验收标准就是这些场景。
第一个场景叫"退款商品应退回库存"，内容如下：假设一位顾客之前从我这里购买了一件黑色毛衣，并且我的库存中有3件黑色毛衣，当他们退回这件黑色毛衣要求退款时，我的库存中应该有4件黑色毛衣。这相当直观。
相关利益者看到这个场景时应该能够判断："是的，这就是退货入库的正常流程。"或者也可能会说："还有另一种可能的情况。"这时你就需要为"退货入库"这个功能记录一个新场景。
关键在于，相关利益者实际上是在帮你用一种正式的语法定义系统行为，而你现在可以根据这种语法来执行测试用例。我再说一遍：你实际上可以根据这份文档执行测试用例。
像Behave和Cucumber这样的BDD工具可以直接使用这份文档，无需进一步编辑或处理，就能执行测试用例，以证明系统确实表现出预期的行为。这会让你的客户满意。
这就是为什么我在每个用户故事中都添加验收标准，我使用Gherkin语法在我们编写的用户故事中定义验收标准。这样一来，在冲刺阶段结束时，就不会对"完成"的定义产生争议，因为这是无可争议的：代码要么表现出这种行为，要么没有。
BDD改善了开发人员、测试人员、产品负责人和其他相关利益者之间的沟通，它通过提供一种接近日常语言的通用语法，相比TDD工具学习曲线更平缓，从而为系统应有的行为提供更精确的指导。
采用BDD方法的工具通常能根据BDD功能规范自动生成技术文档和最终用户文档。清晰的行为可见性有助于生成更高质量的代码，这降低了维护成本并消除了风险。
最后，由于在实际开发之前，BDD的验收标准就已经转化为用户故事和测试场景，因此，自动化测试用例甚至可以在产品测试之前就开始创建测试流程。
在本文中，你了解到BDD从外向内聚焦于系统行为，它站在系统使用者的角度看待系统。BDD使用一种通俗易懂的语法，其主要优势包括改善沟通、统一语法，以及为用户故事提供验收标准。