我最近听说过 BDD,发现它与 TDD 非常相似。
您使用这两个中的哪一个(如果有)?
各自的优缺点是什么?
BDD 与 TDD 类似,但思维方式不同。在 BDD 中,您尝试创建可执行规范而不是测试。这主要是通过使用与 TDD 不同但相似的机制来完成的。
BDD 似乎是对人们声称在做 TDD 但编写集成测试而不是单元测试的许多情况的反应。BDD 的人认为谈论测试具有误导性,因此测试成为规范。这似乎有点形而上学,但背后有一些好主意。
我非常喜欢 BDD = TDD 做正确的阵营。如果您按照 Beck 最初描述的方式进行 TDD - 并且被许多人实践 - 那么基本上没有区别。
BDD 带来的是用于描述过程的语言的一些有趣的变体。通过在描述过程和工具中使用替代术语,BDD 人们希望鼓励更好的实践——这是一个值得称赞的目标。
我已经做 TDD 这么久了,我很难判断这是否真的有帮助。我认为(希望 :-) 我已经学到了 BDD 工具/语言所鼓励的许多课程,因此它们似乎并没有为我提供太多额外的价值。当然是 YMMV——而且我还没有使用 BDD 工具完成一个完整的“现实世界”项目——所以我可能会进行我的个人实验并且推断得太远了。
我猜想BDD 工具/语言可能对被介绍到这种接近开发方式的人们更有用——因为它们避免了与更传统意义上使用的“测试”的混淆。我自己还没有这样做过——如果这里的人有过这样的经历,我会很感兴趣。
BDD 就是运行场景。与 TDD 类似,我们将测试每个场景作为一个故事。
故事将由客户解释......根据故事情节编写场景。像 CUCUMBER 这样的工具使编写场景变得容易。
TDD 和 BDD 几乎相同。不同之处在于我们如何解释它,因此成功的团队最终如何使它为他们工作。
BDD 通过形式化最佳 TDD 实践者的良好习惯来构建 TDD。TDD 是编写优秀软件的开发人员工具或指南,而 BDD 是帮助外部开发的好工具,因为它是使用通用语言开发的,因此可以更多地参与业务。
我的经验是,BDD 有助于协作,当团队中的每个人都参与编写描述系统应该做什么的文档时,使用业务可读、可执行的规范有助于构建一种共享语言。这有助于整个团队一起学习领域的语言。
BDD 是使 TDD 成功所需要的。