tdd

用途

TDD 是一个用于测试驱动开发的技能，当用户希望以测试驱动开发方式实现功能或修复缺陷时使用。它强制执行 RED-GREEN-REFACTOR 循环，并通过多智能体编排将测试编写与实现分离。

主要能力

• 多智能体编排：使用独立的子智能体分别负责测试编写和实现。Test Writer 看不到实现代码，Implementer 看不到规格说明，从而防止 LLM 将实现意图泄漏到测试设计中。
• RED-GREEN-REFACTOR 循环：每个切片依次经历 RED（编写一个失败测试）、GREEN（实现使测试通过）、REFACTOR（重构）三个阶段。
• 垂直切片分解：将功能请求分解为有序的垂直切片，每个切片是一个可测试的行为。切片按由内而外的架构层排序：领域模型、领域服务、应用服务/用例、基础设施适配器。
• 上下文边界约束：明确各智能体可见与不可见的信息，确保测试设计不受实现细节影响。
• 状态持久化：在项目根目录创建 .tdd-state.json 状态文件，支持恢复。
• 测试异味扫描：在写入测试后扫描常见测试异味，如断言轮盘、未知测试、同义反复断言。
• 层级 lint：扫描测试代码中违反层级约束的模式，例如领域层测试不得使用 mocking 库。

使用方式

调用模式：

• /tdd <feature>：交互模式，在切片和每个 RED 检查点暂停等待批准。
• /tdd --auto <feature>：自主模式，运行所有切片而不暂停，仅在不可恢复错误时停止。
• /tdd --resume：从项目根目录的 .tdd-state.json 恢复。
• /tdd --dry-run <feature>：验证模式，完整运行 Phase 0 和 Phase 1，渲染所有提示，但跳过 Task() 调用，不写入任何代码。

工作流程：

• Phase 0：设置（每会话一次）：检测框架和测试运行器、检测语言、验证绿色基线、提取公共 API 表面、发现项目文档、创建状态文件。
• Phase 1：规格分解：将功能请求分解为有序垂直切片，按由内而外排序，分配层级标签，等待用户批准。
• Phase 2（RED）：刷新 API 表面，构造 Test Writer 提示，启动 Test Writer 智能体，写入测试代码，扫描测试异味和层级违规，运行测试确认失败。
• Phase 3（GREEN）：启动 Implementer 智能体使测试通过。
• Phase 4（REFACTOR）：启动 Refactorer 智能体进行重构。

适用场景

• 用户请求 TDD、测试优先或 red-green-refactor 工作流。
• 用户使用 /tdd 并提供功能描述或缺陷报告。
• 用户希望从一开始就强制测试覆盖来添加功能。
• 用户希望通过先编写复现测试来修复缺陷。
• 验证脚本在项目环境中是否工作。
• 在提交完整 TDD 运行前审查提示内容。
• 测试技能变更而不产生副作用。

限制

• 在 --auto 模式下，仅在实现 5 次尝试后失败、回归 3 次尝试后无法自动修复、或脚本错误导致无法继续时停止并询问用户。
• 切片分解始终需要用户批准，即使在 --auto 模式下也是如此。
• 如果现有测试失败，TDD 会停止，因为 TDD 从绿色基线开始。
• 如果项目没有清晰的目录层级映射（扁平结构），则跳过基于路径的验证。
• 具体收费、价格、平台支持等信息暂未提供。