⚡

测试驱动开发Skill tdd

测试驱动开发（TDD）是一种软件开发实践，通过在编写生产代码前先写测试来确保代码质量和功能正确性。它适用于新功能开发、bug修复、行为更改和AI辅助代码生成，强调测试作为可执行规范。关键词：测试驱动开发、TDD、软件测试、代码质量、开发方法、AI辅助测试、测试先行、RED-GREEN重构。

测试 0 次安装 0 次浏览 更新于 3/10/2026

已验证: true 最后验证时间: 2026-02-18T21:55:39.677Z 名称: tdd 描述: 规范TDD适用于人类和AI代理。通过先写测试来更改生产代码，证明RED，实现最小的GREEN，并安全重构。 版本: 1.2 模型: sonnet 调用者: 两者 用户可调用: true 工具: [读取, 写入, 编辑, Bash, Glob, Grep] 别名: [测试专家] 最佳实践:

  • 保持可见的测试场景积压，并一次执行一个场景
  • 在代码更改前证明RED，并在命令输出中保留证据
  • 实现最小的GREEN补丁，仅满足当前失败的测试
  • 在完成前使用有界修复循环和反测试黑客检查 错误处理: 严格 流式传输: 支持

测试驱动开发（TDD）

概述

此技能实现了具有AI特定防护的规范TDD：

  1. 构建或更新场景列表。
  2. 执行恰好一个场景作为可运行测试。
  3. 证明RED。
  4. 实现最小的更改以达到GREEN。
  5. 可选地重构。
  6. 重复直到场景列表为空。

何时使用

适用于：

  • 新功能
  • Bug修复
  • 行为更改
  • 由测试驱动的仓库规模修补
  • AI辅助代码生成，其中测试是可执行规范

仅在以下情况下征求人工批准后绕过：

  • 一次性原型
  • 纯声明性配置编辑，无执行路径
  • 一次性迁移脚本，无需维护

铁律

没有生产代码在没有失败测试的情况下先行

如果代码先写，丢弃并从RED重新开始。

规范循环

步骤0：创建/刷新场景积压

  • 为此任务保持一个短的有序测试场景列表。
  • 按设计信号和风险优先，而不是实施便利。
  • 在执行期间添加发现的场景。

步骤1：选择一个场景并写一个可运行测试

  • 每个周期一个行为。
  • 使用清晰的行为名称。
  • 偏好真实协作者；仅模拟外部边界。

步骤2：证明RED

  • 运行最窄的测试命令。
  • 失败必须是由于缺失行为，而不是语法或设置错误。
  • 记录红色证据（测试文件和失败断言消息）。

步骤3：实现最小的GREEN补丁

  • 仅实现当前红色测试所需的内容。
  • 没有推测性API或不相关的清理。
  • 将补丁限制在当前场景内。

步骤4：证明GREEN

  • 重新运行最窄测试命令。
  • 运行受影响的套件（或包级测试集）。
  • 确认无回归。

步骤5：可选重构

  • 仅在绿色测试时重构。
  • 重构后重新运行相同测试集。

步骤6：重复直到积压为空

AI辅助防护

  • 使用测试作为可执行提示上下文；保持提示简短并专注于测试。
  • 偏好确定性测试（稳定夹具，无非确定性排序）。
  • 使用有界修复循环：每个场景最多3次修复尝试后重新设计。
  • 运行反测试黑客检查：
    • 验证更改的断言仍表达原始要求。
    • 为bug修复任务添加至少一个负面测试。
  • 确保代码不分支于仅测试工件。

记忆加速层

使用轻量级记忆以减少重复设置和诊断：

  • 首选的仓库本地测试/lint/格式命令
  • 重复失败签名和简短修复摘要
  • 重复反模式提醒
  • 可重用场景模板

参考：references/tdd-memory-profile.md

硬规则：

  • 记忆从不绕过RED证明
  • 记忆从不更改规范序列
  • 保持配置文件有界且低噪声

仓库规模和类级指导

  • 对于仓库规模工作，按失败测试集群分解，并为每个循环分配一个集群。
  • 对于类级合成，推导方法依赖顺序，并使用方法级公共测试一次实现一个方法。
  • 通过限制每个循环到一个场景和一个补丁目标来保持长上下文压力低。

验证清单

  • [ ] 场景积压存在并在工作中更新
  • [ ] 每个生产更改映射到至少一个失败然后通过的测试
  • [ ] RED证据捕获（命令 + 失败摘要）
  • [ ] GREEN证据捕获（命令 + 通过摘要）
  • [ ] 在触及范围内无未解决的失败测试
  • [ ] Lint/format/测试命令完成或明确报告为阻塞
  • [ ] 未检测到测试黑客模式

预完成命令（项目范围）

使用项目的实际命令。典型序列：

# 1) 目标测试
pnpm test <目标>
# 2) 受影响套件
pnpm test
# 3) lint
pnpm lint
# 4) 格式检查
pnpm format:check

如果仓库使用不同脚本，替换为本地等效项并报告确切运行内容。

合理化对抗措施

  • “我稍后会添加测试” -> 停止并写当前红色测试。
  • “这太小不值得测试” -> 写一个最小行为测试。
  • “我已经手动测试了” -> 手动运行不替代可执行回归测试。
  • “我花太长时间删除测试前代码” -> 沉没成本；从RED重新开始。

相关文件

  • references/research-requirements.md
  • references/tdd-memory-profile.md
  • testing-anti-patterns.md
  • rules/tdd.md
  • templates/implementation-template.md

研究基础

此技能符合：

  • Martin Fowler TDD (2023年12月11日)
  • Kent Beck 规范TDD (2023年12月11日)
  • Rafique & Misic 元分析，IEEE TSE DOI:10.1109/TSE.2012.28
  • LLM4TDD (arXiv:2312.04687)
  • 代码生成的测试驱动开发 (arXiv:2402.13521)
  • 测试作为提示 (arXiv:2505.09027)
  • SWE-Flow (arXiv:2506.09003)
  • TDFlow (arXiv:2510.23761)
  • 从函数到类扩展TDD (arXiv:2602.03557)

记忆协议

开始前： 阅读.claude/context/memory/learnings.md

完成后：

  • 新模式 -> .claude/context/memory/learnings.md
  • 发现问题 -> .claude/context/memory/issues.md
  • 做出决定 -> .claude/context/memory/decisions.md

假设中断：如果不在记忆中，未发生。