tdd - BDD 是取代还是增强了 TDD？

Question

BDD 是取代 TDD 还是两者一起使用？我一直在读到 BDD 应该只测试用户可以看到的东西。如果是这种情况，是否意味着需要将 TDD 用于用户看不到的服务方法？

Answer 1

BDD 是 TDD 和 ATDD 的替代品(并从它们派生而来)。

BDD 的第一个工具 JBehave 实际上是作为单元测试框架 JUnit 的替代品开始的。目的是让您可以描述(尚未编写的)系统的行为并提供示例，而无需使用“测试”一词，因为在那个阶段实际上是分析，而不是测试。 “测试”这个词，引起了各种困惑!

不同之处在于示例、行为和规范都是问题空间语言，而测试一词是解决方案空间。它往往使人们认为他们了解问题，并正在测试解决方案，如果他们真的不了解，这就是一个问题!

事实证明，避免使用 test 一词有助于人们更全面地探索问题。您可以在 Dan North's original article 中阅读有关此内容的信息.

当 Dan 在 2003/4 年探索 BDD 时，他向当时担任​​业务分析师的 Chris Matts 解释了这一点。克里斯说:“但这就像分析一样!”因此，他们开始探索 Chris 如何对整个系统进行分析，以及其示例如何运作，并且 Chris 意识到这不仅与行为和结果有关，还与上下文中的行为和结果有关。这形成了我们今天所知道的整个“Given, When, Then”语法(当时不叫 Gherkin，因为 Cucumber 不存在)。

因此，Dan 开始在单元“测试”工具之上编写一个场景运行框架，然后将其作为 RBehave 移植到 Ruby，然后变成纯文本并成为 Cucumber。那时，BDD 成为 ATDD 的替代品(当时通常使用单元测试工具使用令人难以置信的程序脚本来完成)。

无论您是在低级别使用 JUnit、NUnit 还是任何其他类型的单元测试框架，这都无关紧要。如果您正在考虑行为示例，并通过这些示例进行讨论，那么您就是在进行 BDD。写下示例很有用，自动化它们也很有用，这就是为什么有像 JBehave 和 Cucumber 这样的 BDD 工具在系统级别工作的原因。

我们真的不需要较低级别的特定 BDD 工具，因为开发人员和测试人员很容易将“测试”映射到“示例”或“应该”而不必担心。

不同之处在于人们可以轻松进行对话，而无需使用“测试”一词。

当您为一个类编写 BDD 时，该类的“用户”通常是另一个类。因此，就像您根据系统用户可以看到的内容编写场景一样，您可以根据另一个类可以看到的内容编写较低级别的示例。来自 BDD 的测试是一个非常好的副产品，但对话是最重要的方面，即使对话必须发生在橡皮鸭身上。