什么是 BDD？

BDD 是一种软件团队合作的方式，它弥合了业务人员和技术人员之间的差距，通过

我们通过围绕具体的、现实世界的示例来集中协作工作，这些示例说明了我们希望系统如何表现。我们在持续协作的过程中，使用这些示例来指导我们从概念到实现的整个过程。

BDD 和敏捷

我们假设您的团队已经在使用某种敏捷方法，以小价值增量来规划工作，例如用户故事。BDD 不会取代您现有的敏捷流程，而是对其进行增强。

可以将 BDD 视为您现有流程的一组插件，这些插件将使您的团队更能兑现敏捷的承诺：及时、可靠地发布满足组织不断变化需求的可用软件，需要一些维护工作和纪律。

我们假设您希望能够快速响应用户反馈，并且仅执行满足这些需求的最小工作量。

BDD 鼓励以快速迭代的方式工作，不断将用户的难题分解成可以尽可能快地流经您的开发流程的小块。

本质上，日常的 BDD 活动是一个三步迭代过程

这样做的目的是使每次更改都保持较小，并快速迭代，每当您需要更多信息时，都会向上移动一个级别。每次自动化和实施一个新的示例时，您都向系统添加了有价值的内容，并且已准备好响应反馈。

我们将这些实践称为“发现”、“制定”和“自动化”。

随着时间的推移，记录的示例会成为一项资产，使您的团队能够继续自信地快速更改系统。代码反映了文档，而文档反映了团队对问题领域的共同理解。这种共同理解在不断发展。

关于每种实践，都有很多东西需要学习。我们将在下面对每种实践进行概括。

构建软件系统最难的部分就是确定要构建什么。

– 弗雷德·布鲁克斯，《人月神话》

尽管 BDD 团队会生成文档和自动化测试，但您可以将它们视为不错的副作用。真正的目标是有价值的可用软件，而实现这一目标的最快方法是让参与想象和交付该软件的人员进行对话。

BDD 帮助团队在适当的时间进行适当的对话，从而最大限度地减少在会议上花费的时间，并最大限度地提高生产的宝贵代码数量。

我们使用结构化的对话，称为发现研讨会，这些对话围绕着用户视角下的系统现实世界的示例展开。这些对话加深了我们团队对用户需求、系统应如何运作的规则以及需要完成的工作范围的共同理解。

它还可能揭示我们理解中的差距，我们需要在知道该怎么做之前获取更多信息。

发现会话的审查通常会揭示低优先级的功能，这些功能可以从用户故事的范围内推迟，帮助团队以更小的增量工作，从而提高他们的工作流程。

如果您是 BDD 的新手，发现是最佳的起点。在掌握发现之前，您不会从其他两种实践中获得太多乐趣。

一旦我们从发现会话中确定了至少一个有价值的示例，我们现在就可以将每个示例制定为结构化的文档。这为我们提供了一种快速的方法来确认我们确实对要构建的内容有共同的理解。

与传统文档相比，我们使用人类和计算机都可以阅读的媒介，因此

通过协作编写这种可执行规范，我们建立了一种用于讨论系统的共同语言。这有助于我们在问题域术语一直使用到代码中。

现在我们拥有了可执行规范，我们可以用它来指导我们开发实现。

每次只取一个示例，我们通过将其作为测试连接到系统来对其进行自动化。测试会失败，因为我们尚未实现它所描述的行为。现在，我们开发实现代码，使用内部系统组件行为的更低级别示例来指导我们，根据需要进行操作。

自动化示例就像导轨，帮助我们使开发工作保持正轨。

当我们以后需要返回并维护系统时，自动化示例将帮助我们了解系统当前正在执行的操作，并安全地进行更改，而不会无意中破坏任何内容。

这种快速、可重复的反馈减少了手动回归测试的负担，从而使人们可以腾出时间做更有趣的工作，例如探索性测试。

阅读下面的主题，深入了解 BDD 的更多信息。