Test driven development

测试驱动开发（TDD）

核心原则

先写测试，看它失败，写最少代码让它通过。

如果你没看到测试失败，你就不知道它是否测试了正确的东西。

铁律

没有先看到失败的测试 = 没有生产代码

先写代码再写测试？删掉，重新来。

• 不要保留做"参考"
• 不要在写测试时"改编"它
• 不要看它
• 删除就是删除

何时使用

永远：

• 新功能
• Bug 修复
• 重构
• 行为变更

例外（需要人类伙伴确认）：

• 一次性原型
• 自动生成的代码
• 配置文件

"就这一次跳过 TDD 吧"？停。那是合理化借口。

红-绿-重构循环

RED — 写失败测试

写一个最小测试展示应该发生什么。

好的测试：

def test_retries_failed_operations_three_times():
    attempts = 0
    def operation():
        nonlocal attempts
        attempts += 1
        if attempts < 3:
            raise Exception("fail")
        return "success"
    result = retry(operation)
    assert result == "success"
    assert attempts == 3

清晰命名，测试真实行为，只测一件事

差的测试：

def test_retry():
    mock = Mock(side_effect=[Exception, Exception, "success"])
    retry(mock)
    assert mock.call_count == 3

模糊命名，测 mock 不是测代码

要求：

• 一个行为一个测试
• 清晰的描述性名称
• 测试真实代码（非必要不用 mock）

验证 RED — 看它失败

强制步骤，不可跳过。

pytest tests/path/test.py::test_name -v

确认：

• 测试失败（不是报错）
• 失败信息符合预期
• 失败原因 = 功能缺失，不是拼写错误

测试直接通过？ 你在测已有行为，修正测试。

GREEN — 最少代码

写最简单的代码让测试通过。不要：

• 加测试不需要的选项
• 重构其他代码
• "改进"超过测试要求的范围

验证 GREEN — 看它通过

强制步骤。

pytest tests/path/test.py::test_name -v

确认：

• 目标测试通过
• 所有其他测试仍然通过
• 输出干净（无错误、无警告）

REFACTOR — 清理

只在绿色之后：

• 消除重复
• 改进命名
• 提取辅助函数

保持测试绿色，不要添加行为。

重复

下一个失败测试 → 下一个功能。

好测试的标准

品质	好的	差的
最小	一件事。名字里有"和"？拆开。	test_validates_email_and_domain()
清晰	名字描述行为	test1、test_works
展示意图	展示期望的 API	隐藏代码应该做什么

为什么顺序重要

"我先写代码再补测试来验证"

事后写的测试立刻通过。立刻通过什么也证明不了：

• 可能测了错的东西
• 可能测了实现而非行为
• 可能漏了边界情况
• 你从来没见过它抓到 bug

常见借口粉碎

借口	现实
"太简单不用测"	简单代码也会坏。写测试只花 30 秒。
"我稍后补测试"	测试立即通过证明不了任何事。
"我已经手动测过了"	临时的 ≠ 系统性的。没有记录，无法重跑。
"删掉 X 小时工作太浪费"	沉没成本谬误。保留未验证代码 = 技术债。
"TDD 太死板，实际点"	TDD 就是实际的：提交前找到 bug（比事后调试快）。
"保留做参考，先写测试"	你会改编它。那就是测试后补。删除就是删除。

红灯 — 停，重来

以下任何情况出现，意味着跳过 TDD：

• 测试之前写了代码
• 代码后补的测试
• 测试立即通过
• 解释不了测试为什么失败
• "我稍后加测试"
• 合理化"就这一次"
• "我已经手动测过了"

以上全部意味着：删代码，用 TDD 重来。

验证清单

完成前检查：

• 每个新函数/方法有测试
• 看到每个测试在实现前失败
• 每个测试因预期原因失败（功能缺失，不是拼写错误）
• 写了最少代码让每个测试通过
• 所有测试通过
• 输出干净
• 测试用真实代码（mock 只在不可避时）
• 覆盖边界情况和错误