--- name: 测试驱动开发 description: 在编写实现代码之前，实施任何功能或错误修复时使用 --- # 测试驱动开发（TDD） ## 概述先编写测试。观察测试失败。编写最少的代码使其通过。 **核心原则：** 如果没有观察到测试失败，就不知道它是否测试了正确的东西。 **违反规则的字面意思就是违反规则的精神。** ## 何时使用 **总是：** - 新功能 - 错误修复 - 重构 - 行为变更 **例外（询问您的人类伙伴）：** - 一次性原型 - 生成的代码 - 配置文件想“这次就跳过TDD”吗？停止。那是合理化。 ## 铁律 ``` 没有失败测试之前，不得编写生产代码 ``` 先写代码再写测试？删除它。从头开始。 **没有例外：** - 不要保留它作为“参考” - 不要编写测试时“适应”它 - 不要看它 - 删除意味着删除从测试开始全新实现。就这样。 ## 红-绿-重构 ```dot digraph tdd_cycle { rankdir=LR; red [label="红\n编写失败测试", shape=box, style=filled, fillcolor="#ffcccc"]; verify_red [label="验证失败\n正确", shape=diamond]; green [label="绿\n最少代码", shape=box, style=filled, fillcolor="#ccffcc"]; verify_green [label="验证通过\n全绿", shape=diamond]; refactor [label="重构\n清理", shape=box, style=filled, fillcolor="#ccccff"]; next [label="下一步", shape=ellipse]; red -> verify_red; verify_red -> green [label="是"]; verify_red -> red [label="错误\n失败"]; green -> verify_green; verify_green -> refactor [label="是"]; verify_green -> green [label="否"]; refactor -> verify_green [label="保持\n绿色"]; verify_green -> next; next -> red; } ``` ### 红 - 编写失败测试编写一个最小的测试，展示应该发生的事情。 <好> ```typescript test('重试失败操作3次', async () => { let attempts = 0; const operation = () => { attempts++; if (attempts < 3) throw new Error('失败'); return '成功'; }; const result = await retryOperation(operation); expect(result).toBe('成功'); expect(attempts).toBe(3); }); ```` 清晰名称，测试真实行为，一件事 <坏> ```typescript test('重试有效', async () => { const mock = jest.fn() .mockRejectedValueOnce(new Error()) .mockRejectedValueOnce(new Error()) .mockResolvedValueOnce('成功'); await retryOperation(mock); expect(mock).toHaveBeenCalledTimes(3); }); ```` 模糊名称，测试模拟而非代码 **要求：** - 一个行为 - 清晰名称 - 真实代码（除非不可避免，否则不使用模拟） ### 验证红 - 观察失败 **强制。永不跳过。** ```bash npm test 路径/到/测试.test.ts ``` 确认： - 测试失败（而非错误） - 失败消息符合预期 - 失败是因为功能缺失（而非拼写错误） **测试通过？** 你在测试现有行为。修复测试。 **测试错误？** 修复错误，重新运行直到正确失败。 ### 绿 - 最少代码编写最简单的代码使测试通过。 <好> ```typescript async function retryOperation(fn: () => Promise): Promise { for (let i = 0; i < 3; i++) { try { return await fn(); } catch (e) { if (i === 2) throw e; } } throw new Error('不可达'); } ``` 刚好足够通过 <坏> ```typescript async function retryOperation( fn: () => Promise, options?: { maxRetries?: number; backoff?: '线性' | '指数'; onRetry?: (attempt: number) => void; } ): Promise { // YAGNI } ``` 过度工程不要添加功能、重构其他代码或在测试之外“改进”。 ### 验证绿 - 观察通过 **强制。** ```bash npm test 路径/到/测试.test.ts ``` 确认： - 测试通过 - 其他测试仍通过 - 输出纯净（无错误、警告） **测试失败？** 修复代码，而非测试。 **其他测试失败？** 立即修复。 ### 重构 - 清理仅在绿色之后： - 移除重复 - 改进名称 - 提取帮助函数保持测试绿色。不要添加行为。 ### 重复为下一个功能编写下一个失败测试。 ## 好测试 | 质量 | 好 | 坏 | | ------------ | ---------------------------------- | -------------------------------------------------- | | **最小** | 一件事。名称中有“和”？拆分它。 | `test('验证邮箱和域名和空白字符')` | | **清晰** | 名称描述行为 | `test('test1')` | | **展示意图** | 演示期望的API | 模糊代码应该做什么 | ## 为何顺序重要 **“我会在之后编写测试来验证它有效”** 代码之后编写的测试立即通过。立即通过无法证明什么： - 可能测试错误的东西 - 可能测试实现，而非行为 - 可能忘记边缘情况 - 你从未看到它捕获错误测试先行强迫你看到测试失败，证明它实际测试了某些东西。 **“我已经手动测试了所有边缘情况”** 手动测试是临时的。你以为测试了所有，但： - 无记录显示你测试了什么 - 代码变更时无法重新运行 - 压力下容易忘记案例 - “我尝试时有效” ≠ 全面自动化测试是系统性的。每次以相同方式运行。 **“删除X小时工作是浪费”** 沉没成本谬误。时间已逝。你现在的选择： - 删除并用TDD重写（再加X小时，高置信度） - 保留并之后添加测试（30分钟，低置信度，可能包含错误） “浪费”是保留无法信任的代码。没有真实测试的工作代码是技术债务。 **“TDD是教条主义，务实意味着适应”** TDD是务实的： - 在提交前发现错误（比之后调试更快） - 防止回归（测试立即捕获破坏） - 记录行为（测试展示如何使用代码） - 启用重构（自由更改，测试捕获破坏） “务实”捷径 = 生产环境调试 = 更慢。 **“之后测试达到相同目标 – 是精神而非仪式”** 否。之后测试回答“这是什么做的？”先行测试回答“这应该做什么？” 之后测试受你的实现偏见影响。你测试你构建的，而非所需的。你验证记住的边缘情况，而非发现的边缘情况。先行测试强迫在实现前发现边缘情况。之后测试验证你记住了一切（你没有）。 30分钟之后测试 ≠ TDD。你获得覆盖率，但失去测试有效的证明。 ## 常见合理化 | 借口 | 现实 | | ---------------------------------- | ------------------------------------------------------------------- | | “太简单，无需测试” | 简单代码也会出错。测试仅需30秒。 | | “我会之后测试” | 测试立即通过无法证明什么。 | | “之后测试达到相同目标” | 之后测试 = “这是什么做的？”先行测试 = “这应该做什么？” | | “已经手动测试” | 临时 ≠ 系统。无记录，无法重新运行。 | | “删除X小时是浪费” | 沉没成本谬误。保留未验证代码是技术债务。 | | “保留作为参考，先行编写测试” | 你会适应它。那是之后测试。删除意味着删除。 | | “需要先探索” | 可以。丢弃探索，用TDD开始。 | | “测试难 = 设计不清晰” | 倾听测试。难测试 = 难使用。 | | “TDD会减慢我速度” | TDD比调试更快。务实 = 测试先行。 | | “手动测试更快” | 手动无法证明边缘情况。每次变更你都会重新测试。 | | “现有代码无测试” | 你在改进它。为现有代码添加测试。 | ## 红旗 – 停止并从头开始 - 代码在测试之前 - 实现后测试 - 测试立即通过 - 无法解释测试为何失败 - 测试“之后”添加 - 合理化“就这一次” - “我已经手动测试了” - “之后测试达到相同目的” - “是精神而非仪式” - “保留作为参考”或“适应现有代码” - “已经花费X小时，删除是浪费” - “TDD是教条主义，我是务实的” - “这次不同因为...” **所有这些意味着：删除代码。用TDD从头开始。** ## 示例：错误修复 **错误：** 接受空邮箱 **红** ```typescript test('拒绝空邮箱', async () => { const result = await submitForm({ email: '' }); expect(result.error).toBe('邮箱必需'); }); ``` **验证红** ```bash $ npm test FAIL: 期望'邮箱必需', 得到未定义 ``` **绿** ```typescript function submitForm(data: FormData) { if (!data.email?.trim()) { return { error: '邮箱必需' }; } // ... } ``` **验证绿** ```bash $ npm test PASS ``` **重构** 如果需要，提取验证用于多个字段。 ## 验证清单在工作完成前： - [ ] 每个新函数/方法都有测试 - [ ] 在实现前观察每个测试失败 - [ ] 每个测试因预期原因失败（功能缺失，而非拼写错误） - [ ] 编写最少代码使每个测试通过 - [ ] 所有测试通过 - [ ] 输出纯净（无错误、警告） - [ ] 测试使用真实代码（除非不可避免，否则不用模拟） - [ ] 覆盖边缘情况和错误无法勾选所有框？你跳过了TDD。从头开始。 ## 当卡住时 | 问题 | 解决方案 | | -------------------- | -------------------------------------------------------------------- | | 不知道如何测试 | 编写期望的API。先写断言。询问您的人类伙伴。 | | 测试太复杂 | 设计太复杂。简化接口。 | | 必须模拟所有东西 | 代码耦合度太高。使用依赖注入。 | | 测试设置巨大 | 提取帮助函数。仍复杂？简化设计。 | ## 调试集成发现错误？编写失败测试重现它。遵循TDD周期。测试证明修复并防止回归。永不修复错误而无测试。 ## 测试反模式添加模拟或测试工具时，阅读@testing-anti-patterns.md以避开常见陷阱： - 测试模拟行为而非真实行为 - 向生产类添加测试专用方法 - 不理解依赖项而模拟 ## 最终规则 ``` 生产代码 → 测试存在且先失败否则 → 非TDD ``` 未经您的人类伙伴许可，无例外。

描述: 更新技能 模型: 自动 名称: 测试员

描述: 更新技能模型: 自动名称: 测试员