行为驱动或测试驱动开发？
我非常喜欢做BDD = TDD阵营。如果您按照Beck最初描述的方式进行TDD并且由许多人实践 - 那么这两者基本上没有区别。
什么BDD带来的表是用来描述程序语言中的一些有趣的变种。通过在流程和工具描述中使用替代术语，BDD民众希望鼓励更好的实践 - 一个值得称赞的目标。
我已经做TDD了这么久，现在它是我很难判断这是否实际上帮助。我认为（希望:-)我已经学到了很多BDD工具/语言鼓励的教训，以至于他们似乎没有为我提供太多额外的价值。当然YMMV--我还没有使用BDD工具完成一个完整的“真实世界”项目 - 所以我可能正在进行我的个人实验并推断太远。
我倒是猜是BDD工具/语言可能更有用民间被引入到接近发展这种方式 - 因为它们避免了更多传统意义上被使用，“测试”整个混乱。我还没有自己做过 - 如果这里的民众有任何这样的经历，我会感兴趣。
BDD与TDD类似，但具有不同的思维模式。在BDD中，您试图创建可执行规范而不是测试。这主要通过使用与TDD不同的词汇表而类似的机制来完成。
BDD似乎是很多，人们声称做TDD，但在编写集成测试，而不是单元测试的情况下的反应。 BDD的人认为谈论测试是误导性的，因此测试成为了规格。这似乎有点形而上学，但它背后有一些很好的想法。
BDD就是运行场景。与TDD类似，我们将测试每个场景作为故事。
故事会由客户来解释..立足于故事情节中的场景将被写入。像CUCUMBER这样的工具可以轻松编写场景。
TDD和BDD几乎相同。不同之处在于我们如何解释它，因此成功的团队最终如何才能为他们工作。
BDD通过正式的最佳TDD从业人员的良好习惯建立在TDD。 TDD是编写优秀软件的开发人员工具或指南，BDD是帮助外部开发的好工具，因为它使用无处不在的语言开发，因此更容易从商业中获益。
我的经验是，BDD帮助协作，并利用业务可读，可执行的规格有助于建立时，大家在团队参与编写描述系统应该做什么文档共同的语言。这有助于整个团队一起学习域名的语言。
BDD是使TDD成功所需要的。