开发与工程 test-driven-developmentautomated-testingunit-testingred-green-refactorrefactoring

测试驱动开发

在实现功能或修复缺陷前,用失败测试锁定预期行为。

FollowSkills 评估 · FSRS-2.0
谨慎使用
52/ 100 五分制 2.6 / 5
1 2 3 4 5 6
1信任安全14 / 25 · 2.8/5

该技能将实施范围限定为开发流程,并要求例外先询问人类伙伴,未见凭据窃取、隐蔽外传或恶意外部操作。扣分在于“删除先写代码”是潜在破坏性指令,缺少备份、回滚和工作区边界;也未说明敏感数据、依赖安全或数据流处理,且发布者身份未由 FollowSkills 验证。

2可靠稳定9 / 20 · 2.3/5

文档结构完整且 RED-GREEN-REFACTOR、异常分支和失败检查较清晰;提供了 npm test 示例以及测试反模式参考。扣分在于未定义测试框架、安装前置条件、跨项目命令适配或无法运行时的诊断流程,示例中的同步 operation 与 Promise 类型声明也存在轻微一致性问题。静态评估不超过10分。

3适用触发9 / 15 · 3.0/5

触发条件明确,面向新功能、缺陷修复、重构和行为变更,且列出原型、生成代码和配置文件等例外。扣分在于“Always”和“无例外”较教条,未充分说明不适用场景、项目已有代码或非测试型任务的边界;未提供中文支持说明,但核心功能不依赖海外服务。

4规范维护9 / 15 · 3.0/5

技能有清晰标题、渐进式流程、示例、检查清单、反模式引用和故障处理表;仓库上下文提供 MIT 许可证、版本号、维护者、更新和贡献信息。扣分在于该技能自身没有版本、变更记录、依赖安装说明或维护责任声明,且链接引用文件的可达性仅由静态材料间接支持。

5有效结果7 / 15 · 2.3/5

该技能直接给出可执行的 TDD 循环、测试质量标准、失败验证和完成检查,核心任务目标清楚,能减少测试遗漏和回归风险。扣分在于没有针对该技能本身的可验证执行结果,严格删除代码规则可能增加不必要成本,并未比较适合快速原型或遗留系统的替代流程。静态评估不超过7分。

6证据核验4 / 10 · 2.0/5

源文件包含具体命令、代码样例、检查清单和失败输出示例,具备一定审计性;仓库还声明存在行为测试和 CI 测试,但所给证据没有展示覆盖该技能关键路径的实际测试结果或工作流。静态评估不超过5分。

证据充分度: 评估于 2026年7月19日 审查版本 d884ae04edeb
上游仓库在本次评估后已有新提交;当前评分仍对应所示审查版本,可能尚未覆盖最新改动。
使用前请注意
  • 执行“删除先写代码”前应确认版本控制、备份和可恢复工作区,避免误删用户已有实现。
  • npm test 只是示例命令;使用前需确认项目的测试框架、依赖和测试路径。
  • 对遗留系统、快速原型和配置变更,不应机械套用“无例外”规则,应先获得用户确认并记录偏离原因。
查看完整评分方法 →

这个 Skill 能做什么,适合哪些场景?

这是 Superpowers 仓库中的单个测试驱动开发技能,要求在编写生产代码前先写测试。它强制执行“红—绿—重构”循环:先确认测试按预期失败,再写最少代码使其通过,最后在保持通过的前提下重构。技能适用于新功能、缺陷修复、重构和行为变更;一次性原型、生成代码和配置文件需要先征得人类伙伴同意。它适合希望减少回归、明确记录行为并在重构时获得测试保护的开发者。

要求开发者为一个具体行为编写最小测试,优先使用真实代码而非模拟对象;运行测试命令确认测试因功能缺失而失败;编写刚好使测试通过的最少生产代码;再次运行测试确认当前测试及其他测试通过且输出无错误或警告;随后只做不改变行为的重构,并为下一个行为重复该循环。它还提供测试质量标准、常见合理化借口、重启条件、完成前检查清单和调试回归测试流程。

  1. 开发者实现新功能时,希望先明确预期行为并避免直接进入实现。
  2. 维护者修复缺陷时,需要用失败测试复现问题并防止回归。
  3. 团队重构已有代码时,希望通过持续通过的测试验证行为未改变。
  4. 测试覆盖不足的旧代码需要改进时,先为现有行为补充测试。
  5. 开发者频繁以手动验证或“之后再测试”为由跳过测试时,需要一套强制流程。

这个 Skill 有哪些优点和局限?

优点
  • 明确要求观察测试失败,从而验证测试确实能捕获缺失行为。
  • 用最小实现限制过度设计,并为后续重构提供保护。
  • 覆盖新功能、缺陷修复、重构和行为变更等常见开发场景。
  • 包含完成前检查清单、调试回归流程和测试反模式提示。
局限
  • 规则非常严格,默认不接受先写生产代码再补测试。
  • 例外仅列出一次性原型、生成代码和配置文件,且需要人类伙伴同意。
  • 示例使用 npm test,具体项目的测试框架和命令未由该技能定义。
  • 该技能本身没有独立安装流程,需通过 Superpowers 集合安装。

如何安装这个 Skill?

该技能没有单独安装说明;它位于 obra/superpowers 仓库的 skills/test-driven-development/。README 说明 Superpowers 是包含 14 个技能的集合,需按所用 coding agent 分别安装。示例:Claude Code 可使用 /plugin install superpowers@claude-plugins-official;Codex CLI 可运行 /plugins,搜索 superpowers 并选择 Install Plugin。其他 harness 的安装方式见仓库 README。

如何使用这个 Skill?

在实现功能、修复缺陷、重构或改变行为前触发该技能。例如向 coding agent 提示:“使用 test-driven-development:先为该行为写一个会失败的测试,运行测试确认失败,再实现最小代码并验证通过。”测试命令示例为:npm test path/to/test.test.ts。一次性原型、生成代码或配置文件应先询问人类伙伴是否例外。

这个 Skill 与同类方案有什么区别?

相较于先实现再补测试,该技能要求测试先回答“应该怎样工作”,并通过观察失败证明测试有效;相较于手动测试,它强调可重复运行、可记录并能持续捕获回归。

常见问题

它能否单独安装?
来源只说明它属于 obra/superpowers 的 14 个技能集合,没有提供该技能的单独安装步骤。
什么时候允许跳过 TDD?
一次性原型、生成代码和配置文件被列为例外,但必须先询问人类伙伴。
如果测试一开始就通过怎么办?
应修正测试,因为这通常表示测试现有行为,而不是验证缺失功能。
它是否要求使用模拟对象?
不要求;规则优先使用真实代码,只有不可避免时才使用 mocks。

同仓库的其他 Skills

均来自 obra/superpowers

相关 Skills