【发布时间】：2011-05-22 16:21:40
【问题描述】：
老实说，我看不出 BDD 和 TDD 之间的区别。我的意思是，两者都只是测试是否会发生预期的事情。我见过如此充实的 BDD 测试，它们实际上算作 TDD 测试，而且我见过如此模糊的 TDD 测试，以至于它们将大量代码置于黑箱中。假设我非常相信两者兼有更好。
这是一个有趣的问题。我从哪里开始？我是否从高级 BDD 测试开始？我是否从低级别的 TDD 测试开始？
【问题讨论】：
【发布时间】：2011-05-22 16:21:40
【问题描述】：
根据我在 Wikipedia 上收集到的信息，BDD 包括验收和 QA 测试，如果没有利益相关者/用户输入就无法完成这些测试。 BDD 也使用自然语言来指定其测试，而 TDD 通常使用编程语言。两者之间可能有一些重叠，但我认为主要区别不是模糊，而是 BDD 的语言。
至于你从哪里开始，这真的取决于你的开发过程，不是吗？我假设如果您是自下而上的，您将首先编写 TDD，一旦达到更高级别，您将使用 BDD 测试这些功能是否按预期工作。
正如 k3b 所说：主要区别在于 BDD 是面向问题域的，而 TDD 是更面向解决方案域的。
【讨论】：
BDD 是从客户的角度，关注整个系统的预期行为。
TDD 是从开发者的角度，专注于一个单元/类/功能的实现。它受益于更好的架构（设计可测试性，模块之间的耦合更少）。
从技术角度（如何编写“测试”）它们是相似的。
我会（从敏捷的角度）从一个 bdd-userstory 开始并使用 TDD 实现它。
【讨论】：
-
嗯... BDD 实际上是从 TDD 级别开始的。给你：blog.dannorth.net/introducing-bdd - 应该有帮助。
老实说，我看不出 BDD 和 TDD 之间的区别。
那是因为没有。
我的意思是，两者都只是测试是否会发生预期的情况。
错了。 BDD 和 TDD 与测试完全无关。没有。纳达。齐尔奇。压缩。尼克斯。一点都没有。
不幸的是，TDD 在几乎所有东西中都有“测试”这个词（不仅在它的名称中，而且在测试框架、单元测试、TestCase（您通常继承自的类）、FooTest（类它通常包含您的测试），testBar（测试方法的典型命名模式），以及许多与测试相关的术语，例如“断言”和“验证”）这导致一些人相信它实际上是 确实与测试有关。所以，一些聪明的人说：“嘿，让我们改个名字吧”以消除任何混淆的可能性。
这就是 BDD。它只是 TDD，将任何与测试相关的术语替换为与行为示例相关的术语：
- 测试 → 示例
- 断言 → 期望
-
assert→should - 单位 → 行为
- 验证 → 规范
- ……等等
BDD 只是带有不同单词的 TDD。如果你做正确的 TDD，你就是在做 BDD。不同之处在于——只要你至少相信 Sapir-Whorf 假设的弱形式——不同的词更容易做到正确。
【讨论】：
-
谢谢@Jörg。语言是 BDD 中最基本的概念之一。唯一缺少的是在编写“测试”之前对对话和发现的关注。我会说有不同；语言和语言唤起的问题会产生影响，而且非常重要。
-
Offtopic：我完全同意“语言是 BDD 中最基本的概念之一”，但我不喜欢“行为”这个词。我更喜欢“利益驱动开发”并将利益放在首位“为了将 {benift} 作为 {rolemeber} 我想要 {feature}。
-
@k3b - 该模板来自 Chris Matts Feature Injection，它唤起了 BDD 在分析空间中的质疑/模型破坏模式。 Chris 参与了 BDD 的形成，但在 Dan North 提出名称时并没有提出模板（他同意功能注入也是一个糟糕的名称）。不过，标签一直是“编写重要的软件”。
-
您能否分享您定义 TDD 与测试无关的来源？我很困惑，因为从软件工程师 (Sommerville) 那里了解到，这是我所学到的：
Test-driven development (TDD) is an approach to program development in which you interleave **testing** and code development (Beck, 2002). Essentially, you develop the code incrementally, along with a **test** for that increment. You don’t move on to the next increment until the code that you have developed **passes its test**. Test-driven development was introduced as part of agile methods such as Extreme Programming. -
否决答案，因为“那是因为没有。”是绝对错误的。有许多参考资料解释了 cucumber.io/blog/bdd/bdd-vs-tdd 的差异，例如
一篇关于 TDD 和 BDD 区别的精彩文章：
应该为您提供您需要知道的一切，包括两者的问题和示例。
【讨论】：
术语不同，但在我的工作中，我使用 TDD 来开发细节，主要用于单元测试，而 BDD 更高级，适用于客户、QA 或非技术人员。
【讨论】：
-
关于 TDD/BDD 的文档确实可以解释。这是我的：stackoverflow.com/questions/738539/tdd-how/45971814#45971814
BDD 是关于让您的 TDD 正确。它为您的 TDD 提供“结构和学科”。它指导您测试正确的事物并进行正确的测试量。这是一篇关于 BDD 和 TDD 的精彩小帖子，
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
【讨论】：
主要区别只是措辞。 BDD 使用更冗长的风格，因此几乎可以像句子一样阅读。
【讨论】：
只是从Matthew Flynn 复制答案，我更同意“TDD 和 BDD 与测试无关”：
行为驱动开发是测试驱动开发的扩展/修订。它的目的是帮助设计系统的人（即开发人员）确定要编写的适当测试——即反映利益相关者所需行为的测试。效果最终是一样的——开发测试，然后开发通过测试的代码/系统。 BDD 的希望是测试实际上有助于表明系统满足要求。
更新
代码单元（单个方法）可能过于精细，无法代表行为测试所代表的行为，但您仍应使用单元测试对其进行测试，以确保它们正常运行。如果这就是您所说的“TDD”测试，那么是的，您仍然需要它们。
【讨论】：
我认为 BDD 相对于 TDD 或任何其他方法的最大贡献是让非技术人员（产品所有者/客户）成为软件开发过程各个级别的一部分。
用自然语言编写可执行场景几乎弥合了需求和交付之间的差距。
如果产品所有者想玩转开发团队编写的代码的行为，他可以自己运行他编写的场景并使用不同的数据集进行测试。
太棒了！客户正处于中心位置，不仅问他真正想要什么，而且还验证和体验可交付成果。
【讨论】：