T
TDD 自主执行
作者：鹿Sir开发工具v1
自主执行计划任务的 TDD 工作流技能。以测试驱动开发实现功能：先写失败测试再最小实现，跑通红-绿-重构循环，内置代码评审关卡、失败根因分析与阻塞任务处理，每个任务原子提交并持续更新计划文件，会话中断后可无损续作。当用户要求「用 TDD 实现这个功能」「先写测试再开发」「按计划任务自主开发」「红绿重构循环」时触发。触发词：TDD、测试驱动、红绿重构、先写测试、自主执行计划、原子提交。
下载量
380
点赞
94
价格
免费
技能文档
---
name: tdd-execution
description: 自主执行计划任务的 TDD 工作流技能。以测试驱动开发实现功能：先写失败测试再最小实现，跑通红-绿-重构循环，内置代码评审关卡、失败根因分析与阻塞任务处理，每个任务原子提交并持续更新计划文件，会话中断后可无损续作。当用户要求「用 TDD 实现这个功能」「先写测试再开发」「按计划任务自主开发」「红绿重构循环」时触发。触发词：TDD、测试驱动、红绿重构、先写测试、自主执行计划、原子提交。
title: TDD 自主执行
category: 开发工具
---
# TDD 自主执行
以测试驱动开发自主执行计划任务的工作流：测试先行、原子任务、证据驱动、进度可持续。每个任务经历「验证基线 → 写失败测试 → 最小实现 → 代码评审 → 提交 → 更新计划」的完整循环。
## 核心原则
- **测试先行**：任何实现前先写失败测试。测试就是「完成」的定义。
- **原子任务**：一个任务 = 一个测试文件 = 一次提交。改动保持小而可审。
- **证据驱动**：不对失败瞎猜。宣布阻塞前必须先做根因分析。
- **进度持续**：每完成一个任务就更新计划文件，进度不因会话中断丢失。
## 技能工作流
### 步骤1：验证基线（Verification Sweep）
动手前先建立事实基线：运行现有测试套件与验证命令，确认当前全绿；记录基线状态，避免把既有失败误判为新问题。
### 步骤2：选取下一个任务
按编号取第一个 pending 状态的任务。同一时间只做一个任务。
### 步骤3：红灯阶段——写失败测试
先定义期望行为，再写任何实现。测试即规格。
1. 阅读任务描述与相关 Gherkin 场景
2. 根据验证命令确定测试文件位置
3. 编写捕获该场景行为的测试
4. 运行验证命令，确认测试**失败**
测试质量标准：
- 标题描述结果而非实现（「应在注册成功后返回确认信息」，而非「调用 register 函数」）
- 测试只验证 Gherkin 场景本身——替换实现而不改测试，测试仍应成立
- 每个测试单一职责
Gherkin → 测试的映射示例：
```gherkin
Scenario: 有效邮箱注册成功
Given 我是新用户
When 我用邮箱 "user@example.com" 和密码 "SecurePass123" 注册
Then 我的账号应被创建
And 我应收到确认信息
```
```typescript
describe('User Registration', () => {
it('should create account and return confirmation for valid registration', async () => {
// Given: 新用户（无需前置设置）
// When: 使用有效凭据注册
const result = await register({
email: 'user@example.com',
password: 'SecurePass123'
});
// Then: 账号创建并返回确认
expect(result.success).toBe(true);
expect(result.message).toContain('confirmation');
});
});
```
**测试意外通过**：说明任务可能已完成——重跑验证基线确认；确实完成则直接更新状态进入下一任务。
### 步骤4：绿灯阶段——最小实现
1. 只写让测试通过所需的最少代码
2. 每次改动后运行验证命令
3. 通过即止
实现纪律：
- 不实现测试未覆盖的功能
- 不过早优化
- 绿灯阶段不顺手重构
**连续 3-5 次尝试仍失败**：停止随机试错，转入根因分析（见步骤 7）。
### 步骤5：代码评审关卡
提交前以独立视角评审实现（可启动独立的评审环节或子代理，保持与实现者视角分离）：
```text
评审请求：
任务：<任务描述>
场景：<相关 Gherkin>
检查项：
- 实现是否满足 Gherkin 场景？
- 代码质量与最佳实践
- 安全考量
- 测试质量
变更文件：<列表>
回复：APPROVED 或 NEEDS_CHANGES（附具体意见）。
```
评审循环：NEEDS_CHANGES → 落实意见 → 确认测试仍通过 → 再次送审；**最多 3 轮**。3 轮后仍未通过：对评审意见本身做根因分析，找出未触及的核心问题——针对性修复，或标记阻塞。
### 步骤6：原子提交与更新计划
提交信息格式：
```
<type>(<scope>): <subject>
<body>
Task: <编号> - <描述>
```
type 取值：`feat` 新功能 / `fix` 修 Bug / `refactor` 重构 / `test` 仅测试 / `docs` 文档。
```bash
git add -A
git commit -m "<message>"
```
一个任务一次提交，不合并打包。提交成功后立即更新计划文件中该任务状态：
```markdown
**Status**: pending → **Status**: complete
```
同时用任务清单工具实时跟踪进度，每完成一项即更新。
### 步骤7：失败处理
**测试修不过**（实现尝试 3-5 次后）：
1. 停止随机试错
2. 做根因分析：用五问法（five-whys）从报错现象和已尝试方案出发，找出真正的根因
3. 按根因修复后重试
4. 仍失败则标记阻塞：
```markdown
**Status**: blocked
**Root Cause**: <根因说明>
```
**评审循环不收敛**（3 轮后）：对评审反馈做根因分析，找出为什么修复总没打到点上；要么针对性修复，要么标记阻塞。
**环境问题**：因环境导致的测试失败——记录问题并报告用户，**不标记任务阻塞**（环境问题需要人工介入）。
### 步骤8：会话中断与续作
计划文件始终反映真实状态：已完成任务标记 complete，当前任务保持 pending，不留部分提交的半成品。续作时：重跑验证基线 → 从第一个 pending 任务继续 → 不重复已完成工作。
### 步骤9：收尾
全部完成：
```markdown
## Work Complete
**Plan**: <计划文件>
**Tasks**: X/X complete
**Commits**: N commits
所有任务已验证完成，可进入最终评审。
```
存在阻塞：
```markdown
## Work Blocked
**Plan**: <计划文件>
**Progress**: X/Y complete
**Blocked on**: 任务 N
Root Cause: <说明>
需要人工介入。
```使用说明
# TDD 自主执行 以测试驱动开发自主执行计划任务：验证基线 → 写失败测试 → 最小实现 → 代码评审关卡（最多 3 轮）→ 原子提交 → 更新计划。失败时先做五问法根因分析再动手，会话中断后可无损续作。 ## 最简用法 ```text 用 TDD 自主执行这份开发计划：plan.md ``` ```text 按红绿重构循环实现用户注册功能，每个任务单独提交 ``` ## 特点 - 测试先行：测试即规格，意外通过即识别重复工作 - 原子任务：一个任务一个测试文件一次提交 - 评审关卡：独立视角评审，3 轮不收敛自动升级根因分析 - 进度可持续：计划文件实时更新，中断续作不丢进度 - 阻塞有据：绝不瞎猜，根因不明不宣布完成
支持平台：Qoder · QoderWork · Claude · Codex 等 AI 编程助手