测试驱动开发Skill：先写失败测试，再写最少代码，让每一行实现都有据可依
- 技能定位：这是一个面向「实现阶段」的架构类 AI 技能，角色设定为「专家」，输出格式为「代码」，专门在你写功能、修 Bug、重构时监督你先写测试、再写实现。
- 核心铁律：没有生产代码，除非先有一个失败的测试；没有亲眼看到测试失败，就不知道它是否测了正确的东西。
- 工作循环：红（写失败测试）→ 验证红（观察它以预期原因失败）→ 绿（写最少代码通过）→ 验证绿（全部通过、输出干净）→ 重构（保持绿色）→ 进入下一个循环。
- 差异化价值：它不是「帮你补测试」的工具，而是一个会拦下你「先写代码、后补测试」习惯的规则执行器，甚至会明确要求你删除先写好的实现代码、从测试重新开始。
- 适合人群：后端/前端开发者、需要长期维护老项目的工程师、以及任何想真正养成 TDD 习惯但屡屡「破戒」的人。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 测试驱动开发Skill |
| 技能英文名 | test-driven-development |
| 技能ID | 12903 |
| 领域分类 | 架构 |
| 角色定位 | 专家角色，作用于「实现」阶段 |
| 输出格式 | 代码 |
| 版本 | 1.0.0 |
| 许可证 | MIT |
| 触发词 | TDD、测试驱动开发、红-绿-重构、测试优先 |
| 关联技能 | 单元测试-测试生成、端到端测试模式 |
它解决什么问题？
绝大多数「TDD 失败」并不是因为团队不会写测试，而是因为流程被悄悄偷换了：先写完实现代码，再回头补一个必然通过的测试。这样写的测试能证明代码在跑，却证明不了代码正确——它可能测错了对象、可能测的是实现细节、可能漏掉了你根本没想过的边缘情况。
这个技能要解决的就是这个「顺序问题」。它把红-绿-重构循环固化成一套可执行的判断规则，并且明确列出各种「合理化借口」并逐条反驳，例如「太简单而不测试」「我之后会测试」「之后测试实现相同目标」，都会被直接识别为违纪信号，要求你删除代码、用 TDD 重新开始。
一键安装 AI 技能提升开发效率的思路
所谓的「一键安装」，本质是把这套专家规则装进你的 AI 编程助手里，让 AI 在你每次提出「帮我实现 XXX 功能」时，先给出一个会失败的测试，而不是直接甩出一大段实现代码。整体思路分三步：
- 确认安装前提：你的 AI 编程环境需要支持「技能 / Skill」机制（例如带技能市场的 IDE 插件或具备技能加载能力的 AI 助手）。技能本身是 MIT 许可的规则文档，不依赖特定语言，TypeScript、JavaScript、Python 等工程均可用。
- 通过技能入口安装：在你的技能管理器或技能市场中，用技能ID 12903 或英文名 test-driven-development 检索并添加；具体的安装命令、导入入口、是否支持本地文件导入等细节，以官方说明为准（本技能详情未提供命令行安装指令，请勿依照臆测的地址操作）。
- 验证是否生效：安装完成后，在对话中直接用触发词试探，例如输入「用测试驱动开发的方式帮我实现一个重试 3 次的操作」。如果技能已生效，AI 的第一反应应该是给出一个失败的测试用例并说明这个测试为什么会失败，而不是直接给实现代码。若它直接输出实现，说明技能未加载或被其他规则覆盖，需回到技能管理器中确认启用状态。
该技能的主要功能和特点
- 强制测试优先的执行铁律：明确规定「没有生产代码，除非先有一个失败的测试」。如果你已经先写了实现，规则要求你删除它，并且不接受「留作参考」「写测试时顺手适配一下」这类折中方案——删除就是删除。
- 完整的红-绿-重构状态机：技能内部用流程定义描述了完整循环，包含两个强制验证节点（验证红、验证绿）和一个重构节点，并明确了分支走向：验证红失败要退回重写测试，验证绿失败要修代码而不是改测试。
- 「观察失败」作为硬性门槛：反复强调测试必须先失败，且失败原因必须是「功能缺失」而非拼写错误。测试一写完就通过，等于在测已有行为，必须修正测试。
- 好测试与坏测试的对照标准：提供「最小化 / 清晰 / 展示意图」三个质量维度，并给出正反示例。比如「重试失败操作3次」是合格命名，而「重试有效」这种模糊命名、以及只断言 mock 调用次数而不验证真实行为，都被判定为坏测试。
- 反过度工程约束：绿阶段只允许写「刚好能通过」的最少代码，禁止顺手加参数、加退避策略、加回调钩子等超出测试范围的功能，明确用 YAGNI 原则约束。
- 合理化借口对照表：内置 11 条常见借口的「借口—现实」映射，并额外列出红旗清单（测试前写代码、测试立即通过、说「是精神而非仪式」等），一旦出现即判定需要重来。
- 收尾验证清单：完成工作前必须逐项确认八个检查点，包括每个函数都有测试、每个测试都先观察过失败、模拟仅在最必要时使用、覆盖边界与错误情况等。
- 卡住时的排查指引：针对「不知如何测试」「测试太复杂」「必须模拟一切」「测试设置巨大」四类困境给出对应解法，把「难测试」直接指向「设计有问题」。
- Bug 修复与 TDD 打通：发现 Bug 时，先写一个能重现它的失败测试，再走循环；并明确「永不修复错误而没有测试」，让测试同时承担修复证明与回归防护两种作用。
和普通「测试生成工具」相比，它强在顺序约束与纪律执行：普通工具关心「有没有测试覆盖」，这个技能关心「这个测试有没有被证明过能抓到错误」。
如何使用该技能？
第 1 步：明确要做的行为，用一句话说清楚
在向 AI 提出需求时，把「要做什么行为」写在最前面，而不是先说「帮我写个函数」。例如：
用 TDD 方式实现：一个表单提交函数，当邮箱为空时返回错误提示「邮件必填」。
第 2 步：红阶段——让 AI 先给失败测试
技能会输出一个最小测试，覆盖单一行为，命名清晰，尽量使用真实代码而非模拟。参考示例：
test('拒绝空邮件', async () => {
const result = await submitForm({ email: '' });
expect(result.error).toBe('邮件必填');
});
输入时可以追加一句「请说明这个测试预期为什么失败」，以强制走完验证环节。
第 3 步：验证红——真正跑一次测试
技能会要求你执行类似 npm test path/to/test.test.ts 的命令（具体命令随你的工程而定）。你需要确认三件事：测试是失败而不是报错、失败信息符合预期、失败原因是功能缺失而非笔误。如果测试直接通过，说明你在测试已有行为，必须回去改测试。
第 4 步：绿阶段——只要最少代码
通过验证后，再让 AI 给出实现。技能会刻意只给「刚好够用」的版本，例如三段循环的重试逻辑，而不会自动附带退避策略、回调通知等尚未被测试覆盖的功能。
第 5 步：验证绿——再跑一次，全部通过
确认目标测试通过、其他测试没被打破、输出里没有多余的错误或警告。如果目标测试仍失败，规则是改代码，不是改测试；如果是其他测试被打破，立即修复。
第 6 步：重构——在绿色状态下清理
只有在全绿之后才允许重构：去掉重复、改好命名、抽取辅助函数，并且重构过程中不新增任何行为。重构结束再跑一次测试，保持绿色。
第 7 步：进入下一个循环
每一个新行为都重新从「红」开始，而不是把多个行为塞进一个测试里。技能明确提示：测试名称里出现「和」字，通常意味着该拆分。
输入输出速查
| 你输入的内容 | 期望的技能反应 |
|---|---|
| 「实现一个带指数退避的重试函数」 | 先反问或先拆分行为，只针对「重试 3 次后成功」写一个失败测试，不直接给完整实现 |
| 「这段代码写好了，帮我补个测试」 | 判定为「测试后置」，提示这不属于 TDD，建议删除实现后从测试重新开始 |
| 「测试写好了，跑通了吗」 | 要求你先执行测试并回报失败信息，确认失败原因正确后才进入绿阶段 |
| 「这个测试太难写」 | 引导你简化接口或引入依赖注入，把「难测试」当作设计信号处理 |
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 测试驱动开发Skill（本技能） | AI 侧的流程纪律专家，管「先写测试还是先写代码」 | 红-绿-重构状态机、验证红/绿强制节点、借口反驳、完成前清单 | 需支持技能机制的 AI 环境，通过技能ID或英文名添加，具体入口以官方说明为准；零编码门槛 | 新功能开发、Bug 修复、重构、行为变更 | 优势是把流程约束真正落地，能拦住「先写后测」；不足是规则严格，做临时原型时会显得「不近人情」，技能本身也承认这类情况需要与人确认 |
| Jest / Vitest 等测试框架 | 测试执行引擎 | 断言、快照、模拟、覆盖率统计 | 需在项目中安装依赖并写配置，有工程门槛 | 所有需要自动化测试的 JS/TS 工程 | 优势是执行能力强、生态成熟；不足是它只负责「跑测试」，不约束你什么时候写测试，测试后置它同样照单全收 |
| Cucumber 等 BDD 框架 | 以自然语言描述行为的协作型测试 | Given-When-Then 场景文件、业务可读 | 需设计特性文件与步骤定义，团队协作成本较高 | 业务与开发共同定义验收标准的项目 | 优势是沟通价值高；不足是搭建与维护成本大，对个人小步迭代偏重 |
| 纯人工自测 | 最原始的方式 | 手动点点看、看日志 | 无门槛 | 一次性脚本、临时验证 | 优势是快；不足是技能明确指出的问题——无记录、无法重跑、代码变更后要重来一遍，压力下容易漏掉边界情况 |
该技能的典型应用场景与实际体验情况
场景一：新功能开发中的「第一行代码」
后端开发者要写一个表单校验逻辑，习惯性打开编辑器就写 if。装上这个技能后，AI 会先把一个失败测试摆到他面前，要求他跑一遍、看到「预期 ‘邮件必填’，得到未定义」之后再继续。实际体验是：最初会有点烦，因为多了一次「跑测试—看到红」的动作；但两三次之后你会发现，这次失败输出本身就是在确认「我测的确实是缺失的功能」，而不是一个碰巧通过的摆设。
场景二：修 Bug 时的回归防护
线上出现「空邮件被接受」的问题。技能要求先写一个能重现该 Bug 的失败测试，再修实现。实际体验上，这个流程多花的时间通常不超过几分钟，但换来的是这个 Bug 被永久钉在测试里——后续任何人改动校验逻辑，只要把空值放过去，测试立刻变红。技能里那句「永不修复错误而没有测试」，在这里体现得最直接。
场景三：接手无测试的老代码
面对一堆没有任何测试的历史代码，最容易出现的念头是「先重构吧」。技能给出的路径不是大改，而是「你在改进它，就为现有代码添加测试」，借由每一次小改动逐步补齐安全网。上手难度中等，需要注意：老代码常见的强耦合会导致「必须模拟一切」，此时技能会提示你去看依赖注入，而不是硬堆 mock。
场景四：代码评审前的自查
提交代码前用技能的验证清单过一遍：每个新函数是否都有测试、是否都观察过失败、是否用了最少代码、输出是否干净。实际体验是这份清单的筛查效率很高，尤其是「测试使用真实代码，模拟仅当不可避免」这一条，能揪出大量只断言 mock 调用次数、实际上什么都没验证的假测试。
整体体验小结：上手难度低（不需要额外配置测试环境，规则随对话生效），效果主要体现在「习惯矫正」而非「代码生成速度」。注意事项有两点：一是它会在你试图走捷径时明确拒绝，需要心理预期；二是技能自身也承认临时原型、生成代码、配置文件属于例外，但要求「咨询你的人类伙伴」，所以别把它当成绝对禁令，遇到例外主动沟通即可。
该技能能为用户带来的价值
- 把「顺序」变成可验证的事实：传统自测最难回答的问题是「你怎么知道你测过了」。技能用「必须观察到失败」这一条，把测试的有效性从主观感觉变成了可以复现的证据。
- 显著降低调试成本：技能的立场很明确——TDD 比调试更快。Bug 在提交前被捕获，远比上线后在日志里翻找要便宜；每一次红灯都是一次零成本的提前暴露。
- 为重构提供安全网：只有测试全绿时才允许重构，且重构中不得新增行为。这意味着重构的每一步都有回归保护，改动胆子可以更大、动作可以更小。
- 沉淀可执行的行为文档：测试名称即行为说明，后来者看测试就知道代码「应该做什么」，而不是靠猜实现「实际做了什么」。
- 降低团队协作门槛：验证清单、好测试标准、借口对照表都是可以直接拿去团队共用的模板，新人不需要理解 TDD 的全部理念，照着清单勾选就能落地。
- 长期的复利价值：短期内每次循环多花的验证时间以分钟计，换来的是一个随项目增长而不断增值的测试资产库；反之，跳过验证留下的未验证代码，技能直接点明它就是技术债务。
常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认它真的生效了？
在支持技能机制的 AI 编程环境中，用技能ID 12903 或英文名 test-driven-development 在技能市场中检索并添加即可；具体安装入口与命令以官方说明为准。验证方式很简单：输入「用测试驱动开发方式实现一个重试 3 次的操作」，如果 AI 第一步给的是失败测试并解释它为什么失败，说明已生效；如果直接给实现代码，说明未加载成功。
Q2：这个技能收费吗？会不会强制我改掉现有工作方式？
技能本身标注的许可证是 MIT，属于开源许可。至于所在平台是否收费，取决于平台自身的计费规则，以官方说明为准。至于「强制」：它确实会在你「先写代码后补测试」时提出删除重写的要求，但技能自身也列了例外情形（临时原型、生成代码、配置文件），并要求在例外情况下咨询你的协作伙伴，所以它是纪律提示器，不是不可绕过的硬锁。
Q3：哪些人最适合用？我是新手会不会太难？
最适合三类人：一是总想「先跑通再说」但事后补不上测试的开发者；二是维护长期项目、被回归 Bug 反复折磨的工程师；三是想养成 TDD 习惯但屡屡破功的人。新手同样适用，因为技能内置了好测试的三个标准（最小化、清晰、展示意图）和卡住时的四种解法，相当于把「怎么开始」也一并教了。
Q4：和直接让 AI「帮我生成单元测试」有什么区别？
关键差别在顺序与证据。生成测试工具关心的是「有没有测试、覆盖率多少」；本技能关心的是「这个测试有没有被证明能抓到错误」。在实现之后补写的测试会立即通过，而立即通过证明不了任何事情——它可能测错了对象、可能测的是实现细节、可能漏了你没想到的边界。技能要的就是那一次「先看到红」。
Q5：我已经写了半天实现代码，现在想用 TDD，必须删掉重写吗？
技能给出的答案很直接：是的。它明确反驳了「删除 X 小时工作是浪费」这一说法，认为这是沉没成本谬误，真正浪费的是保留你无法信任的代码。它也堵住了「留作参考」「写测试时顺手适配」这类变通——因为一旦参照已有实现写测试，你得到的就是「这代码做了什么」，而不是「这代码应该做什么」。若确属临时探索，可以按技能的例外条款与你的协作伙伴确认后再决定取舍。