test-driven-development

test-driven-development skill 概览

test-driven-development skill 实际上做什么

test-driven-development skill 为 AI 代理提供一套严格的 TDD 工作流，适用于功能开发、缺陷修复和行为变更：先写测试，确认它是因为正确的原因失败，再编写刚好能通过测试的最小生产代码，最后在有保障的前提下重构。它的核心价值不是“顺手把测试也写了”，而是强制执行先后顺序，让实现真正由可执行的行为定义来驱动。

谁最适合使用这个 skill

这个 test-driven-development skill 特别适合把 AI 用在真实仓库工作的开发者，尤其是在正确性很重要的场景里：应用功能、服务逻辑、bug 修复、重构，以及防止回归。它尤其适合你希望模型不要一上来就直接写实现，而是先产出更小、更容易验证的步骤时使用。

它真正解决的是什么问题

大多数人安装 test-driven-development，是因为通用编程提示词往往会先生成代码，最后再补测试。这个 skill 会改变这种行为。它帮助你把实现建立在失败测试之上，让代理产出的内容更容易审查，也更不容易凭空编造未经验证的行为。

它和普通“写测试”提示词的真正区别

真正的差异点在于这个 skill 里的“铁律”：没有先失败的测试，就不能写生产代码。这比一般提示词严格得多。它还特别强调，初始失败必须是“正确的失败”，而不是随便出现一个红灯就算完成，这是一条非常实用的护栏，很多浅层 TDD 介绍都会忽略这一点。

安装前必须知道的限制

这是一个流程型 skill，不是某个测试框架的专用工具包。它不会替你设计完整的测试架构，也不会附带辅助脚本或大量参考资料，除了 SKILL.md 和 testing-anti-patterns.md 之外没有更多“开箱即用”的内容。如果你需要深入的 Jest、Pytest、JUnit 或 Playwright 配置指导，这个 skill 更适合当作工作流层来用，而不是完整的测试手册。

如何使用 test-driven-development skill

安装 test-driven-development skill

从仓库安装：

npx skills add https://github.com/obra/superpowers --skill test-driven-development

如果你的环境支持本地 skill 发现，开始做功能开发前请先确认该 skill 已显示为 test-driven-development，并且代理可以调用。

先读这两个文件

对于这次 test-driven-development install 和使用流程，建议先看：

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

先读 SKILL.md，了解工作流和约束。接着读 testing-anti-patterns.md，尤其当你的任务涉及 mocks、测试隔离、UI 测试，或者你已经开始想往生产代码里塞“只为测试服务”的接口时，这份文件非常关键。

先准备好这个 skill 的最小输入

这个 skill 在你提供以下信息时效果最好：

• 要做的功能、bug 或行为变更
• 相关文件或模块边界
• 仓库当前使用的测试框架
• 期望的用户可见行为或系统可见行为
• 对 API 形态、向后兼容性或性能的约束

如果缺少这些上下文，代理仍然可以机械地执行 TDD，但它可能会选错测试层级，或者写出更适配工具而不是更贴合代码库的别扭测试。

把模糊需求改写成适合 TDD 的提示词

较弱的提示词：

Add support for password reset.

更强的提示词：

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

更强的版本给了代理足够的上下文，让它能选对第一个测试，并遵守 red-green-refactor 循环。

把 test-driven-development skill 当作分步工作流来用，而不是一次性生成

一种很实用的 test-driven-development usage 方式是：

1. 先只要求输出第一个失败测试。
2. 检查这个失败是否真的指向目标行为。
3. 再要求给出让测试通过的最小实现。
4. 只有在 green 之后才要求重构。
5. 对下一个小的行为切片重复这个流程。

相比一次性要求完整功能，这种做法通常效果更好，因为这个 skill 本来就是围绕“小步验证迭代”设计的。

正确验证“red”阶段

这个 test-driven-development guide 里的关键点之一是：测试失败本身并不够。失败必须能证明测试瞄准的是正确的、当前缺失的行为。如果测试是因为 import 错误、fixture 损坏，或无关的初始化问题而失败，那么这个循环其实还没有真正开始。

在提示词里，最好明确要求代理说明：测试为什么失败，以及为什么这种失败才是正确的失败。

选对第一个测试

最好的第一个测试，通常是能覆盖“最小但对外有意义”的行为变化。常见的好起点包括：

• 一个 bug 复现
• 一条业务规则
• 一个接口返回变化
• 一个领域方法的行为
• 一次对用户影响明确的 UI 交互

不好的起点则包括：超大的端到端场景、范围很宽的 snapshot 覆盖，或者过早锁死内部实现细节的测试。

一旦出现 mocks，就套用 anti-pattern 指南

如果代理开始过度使用 mocks，辅助文件 testing-anti-patterns.md 就非常重要。这个 skill 明确警告：不要测 mock 的行为，而要测真实行为。这一点对于 test-driven-development for Test Automation 尤其关键，因为 AI 代理经常会去断言一些 mock 占位结果，只因为这些内容比真实输出更容易满足。

如果测试在断言“某个 mock 被渲染了”“某个 mock 以很表面的方式被调用了”，或者为了测试不得不在生产代码里新增只供测试使用的方法，就应该停下来，重新收缩并改写这个测试。

明确要求代理遵守这条铁律

如果模型已经提前写出了实现，这个 skill 自身的建议非常严格：删掉生产代码，从失败测试重新开始。实际操作中不用太“戏剧化”，但你至少应该明确要求代理忽略先前那种投机式实现，按 test-first 的顺序重新生成。

可直接使用的说法：

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

让这个 skill 贴合你仓库现有的测试栈

这个 skill 以流程为中心，所以你需要主动把它锚定到自己的技术栈里：

• Python 服务使用 pytest
• JS/TS 逻辑使用 Jest 或 Vitest
• Ruby 使用 RSpec
• Java 使用 JUnit
• 只有当行为确实属于浏览器层时，才使用 Playwright 或类似工具

如果你的仓库已经有比较成熟的测试金字塔，要明确告诉代理这次变更该落在哪一层。否则，模型很可能默认选择“最显眼”的测试形式，而不是“成本最低但足够有效”的那一层。

面向真实仓库工作的提示词示例

一个靠谱的 test-driven-development skill 提示词可以长这样：

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

这个提示词同时给出了行为、位置、框架和审查标准。

test-driven-development skill 常见问题

如果我已经懂 TDD，还有必要安装 test-driven-development 吗？

有必要，前提是你真正的问题在于：如何让 AI 代理真的遵守 TDD，而不是嘴上讲 TDD。test-driven-development skill 的价值更多不是“教学”，而是给模型施加行为约束。

对新手友好吗？

大体上友好。它的工作流很直接，也写得很明确。对新手更难的部分，其实是选对第一个测试，以及选对测试层级。如果你刚接触测试，建议先把这个 skill 用在小型 bug 修复上，而不是一上来就做大块的新功能。

什么情况下 test-driven-development 不太适合？

对于一次性原型、生成代码，或纯配置修改，这个 skill 的适配度会弱一些，除非正确性风险很高，并且人工审查者依然希望坚持 test-first 纪律。源文档里也明确把这些场景视为需要和人类协作者讨论的例外情况。

它和普通提示词到底有什么不同？

普通提示词常常会说“实现 X，并补上测试”。而这个 skill 改变的是工作顺序，并且把这个顺序视为不可协商。真正的价值就来自这个先后次序：它能减少“脑补式实现”，也让代码审查更容易。

这个 skill 也覆盖框架配置吗？

覆盖得不深。test-driven-development install 很直接，但 skill 本身并不提供大量框架专属的配置文档。它默认你能把代理引导到现有测试栈或仓库约定上。

test-driven-development 也适合做重构吗？

适合。当你需要确保行为保持稳定时，它很适合用于重构。比较实用的模式是：先用测试锁定当前行为，再在 green 测试的保护下进行重构。

它适合 UI 和端到端测试吗？

有时适合，但要格外谨慎。做 UI 工作时，anti-pattern 文件尤其重要，因为 AI 很容易漂移到断言 mock 是否存在、或断言实现痕迹这类错误方向。最好从你能验证的、最小的真实用户行为开始。

如何改进 test-driven-development skill 的使用效果

多给行为，少给解决方案

想获得更好的 test-driven-development usage，应尽量描述预期行为和约束，而不是直接规定实现方案。TDD 最擅长的方式，是由测试定义结果，再让代码从这些检查中自然长出来。

更好的输入：
Users should see an error when uploading files over 10MB.

更差的输入：
Add a fileSizeValidator class and call it from the controller.

第一种写法会给代理留出空间，去找到更干净、也更小的实现。

明确指定你要的测试层级

很多效果差的结果，根源都是测试范围选错了。你需要明确告诉代理你想要的是：

• 单元级业务逻辑
• 围绕 service 或 API 的集成测试
• 浏览器层行为

很多时候，这一个选择比提示词里的其他细节都更重要。

强制缩小每次增量

一个常见失败模式是：一轮里要得太多。如果模型一次写出一整套广泛测试和大块实现，就把范围收窄：

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

这样才能把 test-driven-development 的循环真正维持住。

要求解释为什么第一个测试是正确的

让代理明确说明：

• 为什么这个测试是最小且有用的切片
• 预期会出现什么精确的失败
• 为什么这种失败足以证明该行为目前缺失

这样做能显著提升质量，因为它会在实现开始前，把隐藏假设提前暴露出来。

尽早识别 anti-patterns

最常见的质量下滑包括：

• 测的是 mocks，不是行为
• 往生产代码里加入只为测试服务的方法
• 先写通过的测试，却仍称之为 TDD
• 断言过度绑定实现细节
• 测试一变绿就跳过重构步骤

一旦发现其中一种，不要在现有结果上修修补补；应该直接停掉当前循环，要求重新给出正确的第一个测试。

明确提供仓库约定

当你把这些约定说清楚后，这个 skill 的输出会明显更好：

• 测试命名约定
• 测试文件放在哪里
• fixture 模式
• mocking 策略
• 偏好的断言风格

因为仓库本身附带的支持材料比较轻量，所以这些本地约定会直接影响最终输出质量。

拿到第一版结果后继续迭代

在初始结果出来后，不要只说“继续”或“再多做一点”。更有效的方式是追问具体问题：

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

这是实践中提升 test-driven-development skill 效果的最高杠杆做法：始终把代理约束在这个循环里，而不是让它自己跳步往前冲。

遇到例外情况时，配合人的判断

这个 skill 是刻意设计得很严格的。这是优点，但也可能被过度套用。如果任务只是纯配置变更、生成代码刷新，或一次性原型，最好先判断完整 TDD 是否值得这笔成本。最好的效果来自把它用在那些“test-first 顺序会改变决策质量”的场景，而不是所有“理论上都能用”的场景。