BDD和TDD，什么是正确的工作流程？

Question

我的理解是：

BDD是一种评估软件行为方式并编写接受测试的过程。您需要使用TDD方法编写代码，通过编写方法的单元测试并围绕单元测试构建类来编写代码（编码、测试、重构）。编写代码后，您需要进行测试以检查其是否满足最初的接受测试。

有经验的人可以评论我的解释，并演示如何在一个简单的应用程序中使用这些敏捷原则？我看到有关BDD和TDD的文本在分别的出版物中详细介绍，但我正在寻找这两个过程如何在现实世界的开发中相互补充。

- Alex

Answer 1

尝试将它们视为示例，而不是测试。

对于整个应用程序，我们提出了一个用户可能使用该应用程序的示例。该示例是行为的具体实例，可说明该行为。例如，我们可能会说收银应用程序允许退款。使用该收银机的收银员将熟悉弗雷德为退还微波炉而带回微波炉的情形：

假设弗雷德购买了一台100美元的微波炉
当他为退款带回微波炉时
那么他应该获得100美元返还到信用卡上。

现在很容易想到其他场景；例如，弗雷德获得折扣只退回90美元，或者弗雷德自己损坏了微波炉，我们拒绝退款等。

当我们真正开始编写收银软件时，我们将代码分解成小部分；类、函数、模块等。我们可以描述代码的行为并提供示例。例如，我们可能会说退款计算器应考虑折扣。这只是退款场景的一小部分。我们有一个名为RefundCalculator的类，以及一个具有方法shouldTakeDiscountsIntoAccount的单元测试。

我们可以在注释中放入示例步骤，例如：

// Given a microwave was sold at 10% discount for $100

...

// When we calculate the refund due

...

// Then the calculator should tell us it's $90.

...

然后我们填写代码，将其转换为单元测试，并编写使其通过的代码。

通常，“BDD”是指描述整个应用程序的场景，但实际上，这些想法始于单元级别，原则也是相同的。唯一的区别在于，一个是用户使用应用程序的示例，另一个是类使用另一个类（或函数等）。因此，应用程序外部的BDD类似于ATDD（验收测试驱动开发），而用于类的BDD类似于TDD。希望这可以让您了解这些概念如何互相关联。

唯一的区别是我们摒弃了“测试”这个词，因为我们发现请求人们提供示例比请求测试更容易，而且它有助于让人们思考他们是否理解了问题，而不是思考如何测试解决方案。

此外，这个回答关于“自上而下”（或由外至内）和“自下而上”的区别也可能对您有所帮助。

- Lunivore

Answer 2

你的总结基本正确。标签可能会误导：将自己所做的称为“BDD”的人将编写验收测试和单元测试，将自己所做的称为“TDD”的人将编写验收测试和单元测试。对我来说，这两者之间的区别并不重要。您将阅读到许多人使用此基本过程的不同风味的经验。尝试在您的情况下似乎有意义的方法，并随时准备根据适用于您的工作和不适用于您的工作的内容进行调整 - 这就是敏捷的实质。

- Mike Stockdale

---

这个问题其实围绕着“测试”这个词展开。对于开发人员来说，这可能意义不大，特别是如果我们已经习惯了TDD，但如果你在和商业人士交流时，“测试”就非常重要了。“你能给我一个例子吗？”比“你能给我一个验收测试吗？”容易得多。 - Lunivore

Answer 3

BDD故事有两种方法， 命令式和声明式。对于习惯于编写单元测试脚本的开发人员来说，他们可能更容易编写命令式故事。

然而，在采用敏捷测试优先/测试驱动开发方法时，声明式方法会产生与开发故事紧密相关的BDD叙述。这是因为BDD叙述继续反映业务领域语言而不是编程领域。

如何使用声明式验收测试捕获需求？

- Martin Spamer