TDD 与 BDD 的争论常常被认为是选边站。事实上，他们回答不同的问题。测试驱动开发询问代码是否符合开发人员的预期，而行为驱动开发询问团队是否同意软件应该做什么。

为了使差异具体化，我们为每种方法构建了一个小的折扣功能。我们使用标准库在 Python 3.13 上运行代码，下面的结果来自该运行。 BDD 部分使用我们自己的小型运行程序来展示该机制，因此实际项目将使用 Cucumber 等工具或Behavior 来代替。

简短的回答

测试驱动开发（TDD） 是一种编码实践。您编写一个小的失败测试，​​用最简单的代码使其通过，然后改进设计。测试主要由开发人员用代码编写。肯特·贝克推广了这种做法。

行为驱动开发 (BDD) 是一种源自 TDD 的协作实践，由 Dan North 引入了该术语。开发人员、测试人员和业务人员就系统应如何运行的示例达成一致，用简单的语言编写，然后可以将这些示例自动化。

TDD 与 BDD 对比

特点

以下是我们将实施的业务规则： 1000 件或以上的订单可享受 10% 的折扣。会员订购这些订单可享受额外 5% 的折扣。

这听起来似乎很清楚，但实际上已经很模糊了。会员消费满500元可以享受5折吗？该句子说“那些命令”，所以我们假设不是。请记住这一点，因为这正是 BDD 旨在尽早提出的问题。

使用 TDD 构建它

TDD 遵循一个称为 红色、绿色、重构 的短循环：

这些是我们的测试，每条规则都有一个测试：

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

然后，我们分三个阶段编写代码，并在每个阶段之后运行测试。严格的 TDD 会话一次添加一个测试，这显示了相同的进展：

第一阶段：最简单的事情

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

返回零看起来很愚蠢，但它证明测试实际上可能会失败，并且它通过的一个测试是“无折扣”规则。

第二阶段：添加阈值

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

第 3 阶段：添加成员并清理

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

三人均通过。但仔细阅读这个版本。它给消费满 500 美元的会员提供 5% 的折扣，这不是我们假设的规则的含义。没有测试涵盖该案例，因此没有任何标记。 TDD 仅保护您想要测试的行为。 这是一个真正的限制，也是关于示例的对话如此重要的原因。

为什么周期很重要

• 红色证明测试有效。 从未失败的测试可能没有测试任何内容。
• 绿色让您保持专注。 您只编写需要的代码，这有助于防止过度设计。
• 重构保持高品质。测试让您有信心安全地更改设计。
• 它影响设计。 难以测试的代码通常耦合得太紧密，您会立即注意到。

我们的 pytest 教程 展示了一种更方便的方法来编写此类测试，边界值分析 解释了为什么我们选择 999 和 1000 作为值。

使用 BDD 构建它

BDD 从对话开始，而不是从工具开始。通常这是一个被称为三人组的简短会议，产品人员、开发人员和测试人员讨论具体示例：

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

那个交换会发现我们的 TDD 代码中的问题。然后，他们以一种名为 Gherkin 的结构化格式记录示例：

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

团队中的任何人都可以阅读该内容并说“是的，这是正确的”或“不，这是错误的”。即使您从未将其自动化，该场景也已经完成了有用的工作。

将步骤连接到代码

工具将每个简单语言行连接到一个函数，称为步骤定义。为了展示这个想法，我们自己编写了一个小版本并运行了第一个场景：

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

真正的工具会添加参数，以便单个步骤可以匹配“1000”和“500”，以及报告。结果是活生生的文档：对系统的简单描述，如果不再真实，就会大声失败。

写出好的场景

描述点击和字段 ID 的场景在每次重新设计时都会中断，商业读者不再阅读它们。将用户界面详细信息保留在步骤代码中。这些场景与测试用例与测试场景中的示例非常相似，并且它们也经常用于用户验收测试。

两者一起使用

两者自然地适合“由外向内”的工作流程：

1. 团队就行为达成一致，并编写了 BDD 场景。它失败了，因为什么都不存在。
2. 开发人员使用 TDD 来构建所需的小型单元。
3. 单元测试通过了，最终场景也通过了。
4. 一切都在您的 CI/CD 管道 中运行。

将每一个都保持在正确的水平。您应该为重要行为提供一些场景，并为细节提供许多快速单元测试。我们的单元测试与集成测试指南涵盖了平衡。

工具

何时使用每个

TDD 非常适合以下情况：

• 您正在编写复杂的逻辑，例如定价、解析或权限。
• 您正在修复一个错误，因为您可以先通过失败的测试来重现它。
• 您正在编写经常更改的代码。

BDD 非常适合以下情况：

• 业务规则很复杂，误解的代价也很高。
• 非技术人员确实会阅读并讨论这些场景。
• 多个团队需要对某些行为的行为有一个共同的定义。

在以下情况下，这两种方法都可能太过分了：您正在编写一次性原型或探索不明确的技术想法。许多开发人员首先进行峰值，然后通过测试重写。如果工程之外没有人会关注这些场景，那么 BDD 工具也是一项糟糕的投资。在这种情况下，具有良好名称的简单测试会更简单。

常见错误

• 将BDD视为测试工具。没有协作的Cucumber只是一种冗长的测试编写方式。
• 测试 TDD 中的实现。与私有细节相关的测试在每次重构期间都会中断。
• 跳过重构步骤。您可以在混乱的代码上通过测试。
• 在代码之后编写测试并称之为 TDD。这仍然有用，但你会失去设计反馈。
• 编写了太多 UI 场景。 这些场景变得缓慢且不稳定。请参阅片状测试。
• 追逐覆盖率数字。 良好的覆盖率仍然会遗漏没有人考虑到的行为，正如我们的示例所示。

最后的话

TDD 帮助您构建正确的事物，而 BDD 帮助您构建正确的事物。我们的折扣示例展示了双方：代码通过了所有测试，但简单的对话揭示了错误的假设。在你的下一个小功能上尝试一下。在编写任何代码之前，与同事一起编写三个具体示例，然后一次构建一个失败的测试。

常见问题

继续学习