BDD是TDD的替代品吗？

Question

我想知道BDD是否是TDD的替代品？我现在理解的是,在最终的BDD中,我们不再进行单元测试了.相反,有故事/情景/功能和"测试步骤".它看起来像是我完全取代TDD.TDD死了吗？

Answer 1

一点也不.BDD只是TDD的变种.

在TDD中,您将需求表示为可执行测试,然后编写生产代码以完成测试.BDD除了将这些要求重新制定为更易于阅读的形式之外什么都不做,因此对于查看测试报告的人类读者而言,测试更加冗长.(顺便说一句:要实现这一点,BDD需要比传统的数据驱动单元测试更多的代码...)

就这样.

托马斯

Answer 2

与其他响应者相比,我对此有不同的看法.

Dan North创建了BDD,他在TDD的咨询工作中看到,许多人对"测试"部分感到困惑,因为他们有测试经验,他决定更改名称.所以首先,BDD正是TDD的正确解释.之后,Dan开始扩展使用可执行规范(单元测试)的想法,通过添加另一级规范来驱动实现.他受到用户故事的启发,因此大多数工具实现的最简单的BDD允许您编写需求作为用户故事场景,而不是编写生成单元测试的代码,而不是您从事实现的单元测试.所以现在你看到与TDD相比,还有另一个规范级别 - 用户故事.许多工具包括准备好的用户故事到测试的翻译,所以很多人忘记了它们,就像你一样 但它们仍然存在并且不能完全省略 - 实际上并且在理论上如上所述,编程用户故事效率不高.但这不是重点,您可以使用用户故事从利益相关者那里收集需求,并通过执行验收测试来证明您实现了这些需求.

在BDD中还有很多其他的小东西,你最好阅读Dans博客来理解它们,但重点是BDD是TDD的扩展,即使在实现阶段之外,因此它们不能相互交换或变得无用.

Answer 3

加布里埃尔几乎是对的.

单位级别的根本区别在于BDD使用"应该"而不是"测试".事实证明,当你说"测试"时,大多数人开始考虑他们的代码做了什么,以及他们如何测试它.有了BDD,我们会考虑 - 并质疑 - 我们的代码应该做什么.这是一个微妙但重要的观点,如果你想知道为什么那么强大,请阅读神经语言程序设计 - 特别是在词语影响思想和世界模型的方式.作为一个简单的例子,许多刚接触TDD的人开始将代码固定下来,以便没有人可以破解它.BDDers倾向于提供演示其代码价值的示例,以便人们可以安全地更改其代码.

Dan在与Chris Matts交谈并撰写JBehave时意识到他可以将其提升到场景级别(场景与故事并不完全相同).因为我们已经在单位级别使用"应该",所以开始用英语写东西是有意义的(例如,我倾向于使用"应该给我"而不是"应该返回").验收测试驱动开发--ATDD - 已经存在了很长时间,但这是AFAIK第一次有人用英语与业务利益相关者合作.

它不仅仅是TDD的替代品.这是一种考虑测试的不同方式 - 非常注重学习,故意发现我们可能认为我们知道自己在做什么但没有做到的领域,揭露并帮助我们解决无知和误解.它在许多层面都有效.Chris Matts的特征注入将其带入更高层次的空间,直至项目愿景.

我们仍然会在单元级别编写示例 - 或者说您喜欢的规范 - 但实际上,这种模式远远高于甚至情景.如果你想了解更多,你可能会发现我的博客很有用,但Dan的表现更好.此外,克里斯还有一本关于Real Options的漫画书,其中概述了我提到的一些模式.