行为驱动还是测试驱动开发？ [关闭]答案

【问题标题】：Behaviour-Driven or Test-Driven Development? [closed]行为驱动还是测试驱动开发？ [关闭]
【发布时间】：2008-09-23 15:38:11
【问题描述】：

我最近听说了 BDD，发现它与 TDD 非常相似。

你使用这两个中的哪一个（如果有的话）？

各有什么优缺点？

【问题讨论】：

【解决方案1】：

我非常喜欢 BDD = TDD 正确地完成阵营。如果您按照 Beck 最初描述的方式进行 TDD - 并且许多人都在实践 - 那么基本上没有区别。

BDD 带来的是用于描述流程的语言的一些有趣变体。通过在描述流程和工具时使用替代术语，BDD 人们希望鼓励更好的实践——这是一个值得称赞的目标。

我从事 TDD 已经很长时间了，我很难判断这是否真的有帮助。我认为（希望 :-) 我已经学到了 BDD 工具/语言鼓励的许多课程，因此它们似乎并没有为我提供太多额外的价值。当然是 YMMV——而且我还没有使用 BDD 工具完成一个完整的“现实世界”项目——所以我可能进行了个人实验并且推断得太远了。

我猜 BDD 工具/语言可能对被介绍到这种接近开发方式的人们更有用 - 因为它们避免了与在更传统的方法中使用的“测试”的全部混淆感觉。我自己还没有这样做过——如果这里的人有过这样的经历，我会很感兴趣。

【讨论】：

【解决方案2】：

BDD 与 TDD 类似，但思维方式不同。在 BDD 中，您尝试创建可执行规范而不是测试。这主要是通过使用与 TDD 不同但相似的机制来实现的。

BDD 似乎是对人们声称正在执行 TDD 但编写集成测试而不是单元测试的许多情况的反应。 BDD 的人认为谈论测试具有误导性，因此测试成为规范。这似乎有点玄学，但背后有一些好主意。

【讨论】：

【解决方案3】：

BDD 就是运行场景。与 TDD 类似，我们将测试每个场景作为一个故事。

故事将由客户解释......根据故事情节编写场景。像 CUCUMBER 这样的工具可以轻松编写场景。

【讨论】：

【解决方案4】：

TDD 和 BDD 几乎相同。不同之处在于我们如何解释它，因此成功的团队最终如何让它为他们工作。

BDD 通过形式化最佳 TDD 实践者的良好习惯来构建 TDD。 TDD 是一种用于编写优秀软件的开发人员工具或指南，而 BDD 是一种很好的工具，可以帮助外部开发人员更多地参与到业务中，因为它是使用通用语言开发的。

我的经验是，BDD 有助于协作，并且当团队中的每个人都参与编写描述系统应该做什么的文档时，使用业务可读、可执行的规范有助于构建一种共享语言。这有助于整个团队一起学习该领域的语言。

BDD 是 TDD 成功所需要的。

【讨论】：