TDD：测试驱动开发

很多人以为 AI 来了 TDD 会过时。恰恰相反：AI 越强，TDD 越重要。本章讲清它在 AI 编程里"角色升级"后的新价值。

一、先解释名字

TDD = Test-Driven Development（测试驱动开发）。这里最关键的的不是"有测试"，而是"驱动"两个字：

测试不是代码写完以后补上去的附件，而是反过来驱动实现设计的起点。

经典流程是 Red → Green → Refactor：

1. Red      先写一个会失败的测试
2. Green    写最少实现让测试通过
3. Refactor 在测试保护下重构

二、为什么 AI 时代它反而更重要

因为大模型和工程系统的需求，正好互补：

• 大模型擅长"补全"，但会一本正经地产出看着对、实则错的代码（幻觉）；
• 工程系统需要"验证"，需要一个客观的、可执行的裁判。

在 AI 编程里，TDD 多了一层关键意义：

它把模糊的人类需求，变成了 AI 必须通过的"可执行约束"。

对比一下就懂：

你说	AI 的反应
"做个登录功能"	它直接开始写代码，边界全靠猜
"先写测试，覆盖密码错误、账号锁定、Remember Me、会话过期、多端冲突"	它被拉回工程现实，必须逐条满足

所以 TDD 的价值，从"提升开发纪律"升级成了"给 AI 定义行为边界"。

三、TDD 在 AI 编程里的位置

自然语言需求 → 测试用例 → 代码实现 → 自动验证 → 重构与回归
                (人/AI 写)   (AI 写)   (跑测试)     (形成闭环)

它的价值：

• 行为先于实现：先约定"应该怎样"，再让 AI 去实现；
• 显著降低"AI 乱扩展功能"的概率（不满足测试就没法通过）；
• 天然适合接入 lint、typecheck、unit test、integration test；
• 特别适合和自动修复循环配合（后面 Harness Engineering 的核心）。

四、一个最小可运行示例

我们用 Python 的 pytest 演示"先写失败测试，再补实现"的 Red→Green 循环。

第一步：先写测试（此时实现还不存在，测试必然失败）

# 环境：终端，Python 3.11 + pytest
# test_cart.py
from cart import add_item, total

def test_total_with_discount():
    cart = add_item(add_item([], price=100), price=50)
    # 打 9 折：(100 + 50) * 0.9 = 135.0
    assert total(cart, discount=0.1) == 135.0

先跑测试，看到 Red（ModuleNotFoundError: No module named 'cart'），符合预期——因为实现还没写。

第二步：写最小实现让它通过（Green）

# 环境：终端，Python 3.11
# cart.py
def add_item(cart, price):
    return cart + [price]

def total(cart, discount=0.0):
    return sum(cart) * (1 - discount)

再跑（环境：终端）：

python -m pytest test_cart.py

预期输出（已实际运行验证，Python 3.10 + pytest 9）：

test session starts
platform win32 -- Python 3.10.11, pytest-9.0.3, pluggy-1.6.0
collected 1 item

test_cart.py .                                                           [100%]

1 passed in 0.01s

第三步：重构——在有测试保护的前提下，把实现改得更健壮（比如金额为负要报错），而不怕改坏行为。

💡 关键：AI 在这个循环里最适合扮演"第二步的实现者"。测试是你给它划的跑道，跑道在，它就不会乱跑。

五、TDD 的边界

TDD 非常擅长回答：

• 这个函数应该返回什么？
• 这个模块在什么输入下应该如何工作？

但它不擅长回答：

• 我们为什么要这样设计系统？
• 这个需求边界到底是什么？
• 多个模块之间职责如何划分？

所以 TDD 更像验证层，不是规划层。规划层的空白，正是 SDD 规格驱动开发 要补的。

⚠️ 安全提示：让 AI 生成测试时，警惕它为了让测试"变绿"而删除断言、放宽预期或 mock 掉真正该验证的逻辑——这叫"测试造假"。审查时不只盯"通过没有"，更要看"断言是否真的在约束行为"。

六、本章小结

• TDD 的核心是"测试驱动实现"，不是"事后补测试"。
• 在 AI 编程里，TDD 升级为"给 AI 定义可执行的行为边界"。
• 它是验证层，回答"对不对"；不负责回答"要做什么"——那是 SDD 的活。

七、下一步

• 继续阅读：SDD 规格驱动开发，本系列的核心主线。