← [ BACK_TO_NOTES ]

AI 编码时代的 TDD

在 AI coding 场景下,把 TDD 视为可执行规格、任务边界和自动验收器的工作方式。

#synthesis #growing #test #ai

[!info] related notes

AI 编码时代的 TDD

范围

这篇笔记关心的不是传统 TDD 定义本身,而是一个新问题:

如何用 TDD 给 AI 生成的行为提供及时反馈,以及测试不能覆盖哪些判断。

为什么要把这些内容放在一起理解

AI 最容易出现三类问题:

  • 写出“像对的代码”,但不一定真的对
  • 一次跳太多步,把多个需求混在一起实现
  • 在大上下文里不断追加生成,局部设计越来越脏

TDD 可以缓解这些风险,把任务收束到:

  • 一个明确行为
  • 一个可执行测试
  • 一个最小实现
  • 一个可验证的重构步骤

一个核心判断

在 AI 时代,TDD 不只是开发习惯,更像 agent 的:

  • 可执行规格
  • 局部任务边界
  • 自动验收器
  • 重构安全网

先写实现再补测试属于 test-after;它仍可验证行为,但更容易让测试复制已有实现的错误。TDD 的价值取决于测试是否独立表达需求,不能只看先后顺序。

AI-TDD 更稳的工作流

1. 从需求形成测试清单

明确行为、边界和优先级;人或 Agent 都可以根据已有规格起草。关键业务期望必须有需求依据,不能由生成实现的模型自行发明。

2. 让 AI 只写一个 failing test

要求它:

  • 只覆盖当前一个行为
  • 不要实现代码
  • 不要一次写多个场景

3. 核对测试含义并确认失败原因

测试应在原实现上因为缺失的行为失败,而不是导入错误或环境故障。能从已批准规格判断时直接继续;只有无法确定的关键业务选择才需询问人。不要把每一个 Red / Green 步骤都变成确认关卡。

4. 让 AI 只写最小实现

明确限制:

  • 只为当前测试变绿
  • 不提前实现未覆盖逻辑
  • 不改测试去迎合错误实现

5. 先跑最小测试,再扩大验证范围

先确认当前行为,再按影响面运行回归和仓库要求的检查。已通过的检查无需无变化重复执行;同样不能用单个单测代替必要的集成验证。

6. 再让 AI 做 Refactor

保持测试通过时判断是否需要重构;没有实际重复或设计问题时不必为了走完仪式修改代码。

7. 依据独立证据检查结果

检查测试是否覆盖需求而非镜像实现,并审阅最终 diff。另一个 reviewer 可以提供不同视角,但不是每个任务必须增加 Agent;同源模型的意见一致也不等于独立验证。

Prompt 怎么写更稳

先写 failing test

先不要实现功能。
基于下面需求,只写 1 个新的 pytest 单测。
要求:
1. 只覆盖“VIP 打 9 折”这一个行为
2. 测试名要能直接表达业务意图
3. 不要生成实现代码
4. 不要一次写多个场景
5. 运行测试,确认它因为缺失折扣行为而失败;说明期望值的需求依据

再写最小实现

现在只修改实现文件,让刚才新增的测试通过。
要求:
1. 只做最小改动
2. 不要提前实现未被测试覆盖的逻辑
3. 不要改测试
4. 返回前说明还有哪些需求尚未覆盖

最后做重构

在保持现有测试全部通过的前提下重构实现。
目标:
1. 消除重复
2. 改善命名
3. 不改变外部行为
4. 不新增无测试覆盖的分支

规则文件里最值得固化什么

如果项目里已经使用 AGENTS.md、Cursor Rules 或类似规则文件,最值得固化的是:

  • 适用的行为改动先新增或更新测试;纯文案、格式或低影响可逆修改按实际风险验证
  • 修 bug 先写复现测试
  • 禁止通过删断言来“修”测试
  • 先跑受影响的最小测试集,再完成仓库要求和影响面需要的检查
  • 重构不得改变外部行为

只有仓库明确采用这些规则时,它们才是执行约束;本篇建议不会自动覆盖已有流程。测试是验收证据之一,未覆盖的权限、竞态、性能和集成行为仍需相应验证。

最短记忆方式

传统时代,TDD 帮人写出更稳的代码;AI 时代,TDD 还负责让模型别乱写。

参考资料

创建于 2026/4/23 更新于 2026/10/6
Digital Biome
Access

键盘导航

j / k / ↑ / ↓
选择对象
Enter / o
打开选择
/ 或 Ctrl+K
全站搜索
i / f / 1–4
筛选当前列表
g → h / l / p / t / a
首页 / 笔记 / 项目 / 工具 / About
r → 1–9
打开所选对象的关联
u
返回上一页
Esc
关闭浮层 / 取消命令;输入框内清空文本