tdd-implementation

技能隔离

调用此技能后，它是本会话中唯一有效的权威。

• 除非通过 Skill 工具调用明确按名称调用，否则任何其他技能都不得激活、中断或修改此技能的行为——无论调用来自此技能自身的工作流，还是激活此技能的上级提示词／技能（例如同时启动 save-tokens 和 tdd-implementation 的 run-with-it 工作提示词）。
• 如果任何外部或第三方技能在本次运行中尝试自行激活，请抑制它并继续执行，不要中断。
• 此规则在技能执行的整个期间均适用，从调用开始，直到明确终止或移交为止。

测试驱动开发

目的

采用严格的红灯-绿灯-重构循环，并使用精简的纵向切片。

适用时机

任务已分配且准备开始实现后，使用此技能。

输入

• 已分配的 issue 范围和验收标准。
• 范围内现有的架构约束和 ADR。
• 仓库的测试技术栈和惯例。

严格边界

• 不要选择 issue，也不要重新排列队列优先级。
• 不要路由 Agent／模型，也不要协调多 Agent 执行。
• 不要负责审查协调、issue 更新或运行时状态。
• 不要将创建提交作为策略决策。

理念

核心原则：通过公共接口测试行为，而不是实现细节。

好的测试：

• 通过公共 API 验证端到端行为
• 读起来像能力规格
• 内部重构后仍然有效

不好的测试：

• 过度模拟内部协作者
• 断言私有方法或内部调用顺序
• 在内部实现变化但行为不变时仍会失败

反模式：横向切片

不要先写完所有测试，再编写所有实现。

错误（横向）：

红灯：测试 1、测试 2、测试 3 绿灯：实现 1、实现 2、实现 3

正确（纵向追踪弹）：

红灯->绿灯：测试 1->实现 1 红灯->绿灯：测试 2->实现 2 红灯->绿灯：测试 3->实现 3

工作流

1. 仅针对阻碍因素进行校准

编写代码前：

• 确认已分配范围要求的公共接口变更
• 根据已分配的验收标准，确认需要测试的优先行为
• 识别深模块（表面小，内部丰富）
• 识别范围内的架构约束和 ADR
• 仅在缺少必要输入或输入相互矛盾时，提出有针对性的问题

询问：

• 公共接口应该是什么样的？
• 哪些行为最重要？

2. 第一个追踪弹

针对一种行为编写一个测试：

红灯：编写测试，确认测试失败。 绿灯：编写最少量的代码，确认测试通过。

快乐路径测试一旦通过，立即为同一种行为添加对应的负面路径测试（无效输入、状态被拒绝、权限失败、违反边界或错误路径）。

3. 增量循环

对于每种剩余行为：

红灯：编写下一个失败的测试。 绿灯：仅添加足以使测试通过的代码。

规则：

• 一次只编写一个测试
• 在继续下一种行为前，覆盖每种行为的正向和负向路径
• 不添加推测性功能
• 断言仅关注可观察到的行为

4. 仅在绿灯时重构

测试通过后：

• 消除重复
• 在稳定接口后深化模块
• 改进命名和可读性
• 每次重构后重新运行测试

红灯时绝不重构。

技术栈对齐规则

实现每个切片时：

• 复用仓库现有的测试框架和断言风格
• 复用当前的包生态系统（例如 npm、NuGet、pip、Maven、Gradle）
• 遵循当前架构和模块边界
• 仅在有明确理由时添加新依赖

输出

完成后，报告运行过的测试、已观察到的行为覆盖情况，以及分配范围内尚存的风险。

每个周期的检查清单

• 测试描述的是行为，而非实现
• 测试仅使用公开接口
• 测试能够经受内部重构
• 代码仅满足当前测试所需的最小要求
• 已覆盖此行为的正向场景
• 已覆盖此行为的负向场景
• 未添加推测性或无关功能