tdd — 强制测试驱动开发,不跳过测试

tdd 快速入门

强制 AI 按 RED → GREEN → REFACTOR 循环写代码,让”先写实现后补测试”变成不可能。

这是什么?解决什么问题?

测试驱动开发(TDD)是个老话题,它的核心循环非常清晰:

1. RED:先写一个失败的测试(因为还没有实现);
2. GREEN:写最少的实现代码让测试通过;
3. REFACTOR:在测试保护下,清理实现,提升可读性/性能。 但 90% 的团队嘴上说 TDD,实际是”先写代码,上线前赶测试”——尤其是用 AI 写代码,默认行为是直接给实现,测试要你主动要求。 Matt Pocock 的 tdd Skill 把这个循环强加给 AI:

• AI 想写实现,先被强制”先写一个会失败的测试”;
• 测试必须真实运行(命令可见),而不是嘴上说”应该失败”;
• 改实现时,测试必须保持绿;
• 重构时,测试覆盖不能减少。 这样保证 AI 写的每一行生产代码都有对应的测试保护。 适合:所有”用 AI 写代码但又担心质量”的工程师,尤其是金融/医疗/企业级应用。

准备工作

• 一个支持 SKILL.md 的 agent
• 一个带测试框架的项目(Jest / Vitest / pytest / Go test / JUnit 均可)
• 测试能跑通的命令(如 npm test)
• 5 分钟

3 步快速上手

第 1 步:克隆并软链

git clone https://github.com/mattpocock/skills.git
ln -sf "$(pwd)/skills/tdd" ~/.claude/skills/tdd

OpenCode 用户把目标路径改为 ~/.config/opencode/skills/,Cursor 用户改为 ~/.cursor/skills/。

第 2 步:确认 Skill 加载

cat ~/.claude/skills/tdd/SKILL.md | head -30

应当能看到 RED/GREEN/REFACTOR 三个阶段的具体动作定义(必须真实跑测试、必须看到失败、必须看到通过、refactor 时测试仍绿)。重启 agent,/skills list 看到 tdd 即 OK。

第 3 步:用 Skill 写第一个 TDD 函数

在 agent 对话里说:

[开 tdd]
用 TDD 帮我写一个 formatPrice(amount: number, currency: 'USD' | 'CNY'): string 函数。
规则:amount 保留 2 位小数,US 用 $,CN 用 ¥,负数前加 -。

观察 AI 行为: Step 1 (RED):AI 先写 src/formatPrice.test.ts:

import { formatPrice } from './formatPrice';
test('formatPrice USD 100 → "$100.00"', () => {
expect(formatPrice(100, 'USD')).toBe('$100.00');
});

跑 npm test,必须看到失败(因为还没实现)。 Step 2 (GREEN):AI 写最少代码让测试绿:

export function formatPrice(amount: number, currency: 'USD' | 'CNY'): string {
const sign = amount < 0 ? '-' : '';
const abs = Math.abs(amount).toFixed(2);
return `${sign}${currency === 'USD' ? '$' : '¥'}${abs}`;
}

Step 3 (REFACTOR):AI 重新看代码,可能把 currency 抽成字典,跑测试保持绿。 整个过程你都能看到 AI 在做事的”证据”(终端输出、文件 diff),而不是黑盒说”写好了”。

常见踩坑

1. RED 阶段 AI 不真跑测试:“写好了应该失败”不算数,要让 AI 把 npm test 实际跑起来,把失败信息贴出来。Skill 默认会强制。
2. GREEN 阶段过度实现:写了一堆测试没要求的功能,违反”最少实现”原则。明确说”先只通过当前测试,不要加额外逻辑”。
3. REFACTOR 阶段偷偷改测试:refactor 是改实现不是改测试,如果测试变了,可能掩盖实现 bug。Skill 会显式禁止。
4. 测试不写断言:AI 写出 test('it works', () => {}) 这种空测试,Skill 应当能识别并提示”无效测试”。
5. 依赖外部服务时跑不通:测试需要数据库 / 网络时,没 mock 导致 RED 阶段也连不上。提前准备好 mock 框架(MSW、testcontainers)。
6. 100% 覆盖率执念:TDD 不等于 100% 覆盖,branch coverage 100% 是过度目标,关注核心业务路径即可。

初级用法

• 每个新函数都 TDD:写工具函数、helper、纯函数,先开 tdd Skill,养习惯。
• 修 bug 走 TDD:发现 bug 后,先写一个能复现 bug 的测试(RED),看到失败,再修实现(GREEN)。

高级玩法

• CI 强制 RED/GREEN 日志:在 PR 里贴 AI 跑测试的终端输出,reviewer 一眼能看出是不是真 TDD。
• TDD + Property-based Testing:Skill 跑完后追加”再补 3 个 fast-check 属性测试”,覆盖边界。
• 配合 mutation testing:用 Stryker/Stryker4s 验证测试”真的能抓到 bug”,而不是只跑过。

小技巧

• 测试名要能”读出来就知道在测什么”,如 formatPrice should return $100.00 when amount is 100 and currency is USD,Skill 会主动用这个风格。
• 一个测试只测一个 case,不要塞 5 个 expect 进同一个 test。
• 边界值、空值、负值、极值,Skill 默认会问”还要测哪些 case”,回答它。
• 跑测试时设 --bail(Jest)/-x(pytest),第一个失败就停,节省时间。
• 写完 TDD 三个循环,顺手 git add -A && git commit -m "feat: formatPrice",留下清晰历史。

参考链接

• 仓库主页
• Matt Pocock 个人站
• 《Test Driven Development by Example》(Kent Beck)
• Jest 文档
• pytest 文档
• fast-check
• 相关 Skill:diagnose、caveman、security-auditor