incremental-tdd

测试驱动开发（Red-Green-Refactor）

此技能要求你以紧凑的 TDD 循环开展工作：一个失败的测试、一次实现，然后重构。它倾向于采用纵向切片和深模块，让测试保持可靠、稳定，并专注于真实行为，而非实现细节。

此技能附带了一些额外文档，可供你参考其中的理念和示例：

• deep-modules.md – 深模块为何能让 AI 驱动的 TDD 更轻松、更安全。
• refactoring.md – 安全重构的模式。
• interface-design.md – 如何为 TDD 设计接口。
• mocking.md – 如何以及何时使用模拟，同时不自欺欺人。
• tests.md – 如何以及何时使用模拟，同时不自欺欺人。

需要设计或重构方面的指导时，请打开并阅读这些文件，不要凭猜测行事。

适用场景

当用户遇到以下情况时，使用此技能：

• 想要使用 TDD 构建功能或修复 Bug。
• 提到“red-green-refactor”、“test-first”或“先写测试”。
• 想要编写可靠的集成测试或模块级测试，以驱动设计，而非脆弱的单元测试。
• 正在运行较长的“Ralph”循环或自主 Agent，并希望提高改动质量。

如果需求不明确，建议先使用 /grill-me 和 /spec-writer，然后再回到这里执行。

整体工作流

上下文明确时可以压缩步骤，但要遵守 red → green → refactor 的纪律。

1. 明确行为和接口

   • 确认从外部看应具备哪些行为：哪些输入、输出和可观察效果很重要。
   • 确定或设计用于展现这些行为的接口（公共函数、处理程序、端点等）。
   • 优先采用深模块：模块数量更少、规模更大，并在其上提供精简且稳定的接口。
   • 如有需要，打开 deep-modules.md，并调整接口设计以符合其中的理念。

2. 选择下一个纵向切片

   • 根据 PRD 或问题描述，选择一个精简的纵向切片：一种能够通过系统中的真实路径进行验证的行为。
   • 避免只做横向切片，例如孤立地“创建 DB 表”或“编写全部 UI”。
   • 与用户确认（或通过注释说明）该切片完成后应证明什么。

3. Red：编写一个失败的测试

   • 使用选定的接口编写一个测试，表达该切片所需的行为。
   • 尽量让测试贴近“真实调用方会如何使用”，即使是在模块级别进行测试也如此。
   • 优先使用真实协作者或轻量级伪对象，而非大量模拟。拿不准时，请参阅 mocking.md。
   • 运行测试，并确认它因预期原因失败。

4. Green：编写最精简的实现

   • 打开相关的生产代码文件，编写能让测试通过的最简单实现。
   • 不要过度泛化、添加未使用的参数，或实现尚未经过测试的未来行为。
   • 重新运行测试，确保新测试通过且整个测试套件仍然全部通过。

5. Refactor：安全地改进设计

   • 测试全部通过后，检查是否存在重复、笨拙的接口或泄漏的抽象。
   • 进行小幅重构，并频繁运行测试，确保行为保持不变。
   • 将 deep-modules.md 和 refactoring.md 作为改进边界和深化模块的指南。
   • 设计达到当前“足够好”的程度后即可停止；完成后续切片时还可以再次重构。

6. 重复循环

   • 选择下一个切片或行为，然后重复 Red → Green → Refactor。
   • 每个循环都应足够小，以便在出现问题时能够理解并撤销。
   • 随着开发推进，让测试聚焦于行为，避免将其耦合到偶然的实现细节。

行为与规则

1. 始终遵循循环。 编写大型生产代码块之前，必须先有一个失败的测试。
2. 一次编写一个测试。 不要一次生成数十个测试。根据行为需求逐步添加测试。
3. 优先编写更高层级的测试。 条件允许时，优先选择能覆盖真实流程的集成测试或模块级测试。
4. 防止不诚实的测试。 避免编写即使实际行为已损坏也能通过的测试；检查是否存在明显的误报。
5. 愿意修改自己的代码。 如果出现更好的设计，就把之前编写的代码视为可弃用；依靠测试保障安全。
6. 使用随附文档。 如果不确定模块结构、重构或模拟方式，请打开链接的 Markdown 文件，而不是凭空编造模式。

示例流程

用户： “使用 TDD 实现每周管理员摘要邮件。我已经有 PRD 和 issue。”

你（高层步骤）：

1. 浏览 PRD 和 issue，找出第一个纵向切片（例如，“计算单个团队的每周指标”）。
2. 设计或确认负责计算指标的模块接口；查看 deep-modules.md 获取指导。
3. 针对“给定上周的事件，计算团队 X 的摘要对象”编写一个失败的测试。
4. 编写最少量的代码使测试通过，然后在保持测试通过的同时重构模块。
5. 对其他行为重复上述过程（多个团队、筛选条件、性能约束、错误处理），始终遵循红—绿—重构。