tdd

你现在处于 TDD 模式。请严格遵循测试驱动开发规范。

任务： $ARGUMENTS

评估：首先确定你的场景

• 全新代码：新代码或经过充分测试的现有代码 → 标准 TDD 循环
• 遗留代码：难以测试的现有代码 → 特征测试 → 重构 → TDD

全新代码的 TDD 规则——严格执行：

1. 一次只处理一个测试用例

   • 恰好编写一个失败的测试用例
   • 编写最精简的代码使其通过
   • 如有需要，进行重构，同时确保测试保持通过
   • 将整个循环作为一个提交

2. 提交要求

   • 每个提交：测试 + 实现 + 文档更新
   • 提交说明：Add [specific behavior] with test
   • 切勿提交失败的测试
   • 所有相关更改都放在同一个提交中

3. 工作流约束

   • 进行任何实现之前，先问：“这一个具体的测试用例是什么？”
   • 拒绝批量实现请求
   • 仅专注于当前失败的测试
   • 代码更改需要更新文档时，应一并更新

4. TDD 循环阶段

   • RED：编写失败的测试，并确认失败原因正确
   • GREEN：编写通过测试所需的最精简实现（不添加额外功能）
   • REFACTOR：在确保测试持续通过的同时改进设计

遗留代码的 TDD 规则：

评估阶段：

• 找出当前代码难以测试的原因（耦合紧密、关注点混杂、依赖项等）
• 判断重构是否能提高代码的可测试性
• 制定最安全的重构方案

遗留代码 TDD 工作流：

1. 先编写特征测试——编写测试，捕捉当前行为，作为安全网
2. 重构以提高可测试性——提取函数、注入依赖、分离关注点
3. 添加针对性的单元测试——测试新提取或重构的组件
4. 对新行为采用 TDD——新功能遵循全新代码规则

提交顺序示例：

• “为用户身份验证流程添加特征测试”
• “将密码验证提取为独立函数”
• “为密码验证逻辑添加单元测试”
• “添加密码强度要求并附带测试”

核心原则：

• 没有安全网（特征测试），绝不重构
• 只进行让代码可测试所需的最小更改
• 将重构聚焦于你需要修改的特定区域
• 必要时使用 Michael Feathers 的“遗留代码困境”技术

何时采用此方法：

• 修改未经测试的现有代码
• 代码包含难以模拟的依赖项
• 紧密耦合的函数混杂了多个关注点
• 遗留代码在设计时未考虑测试

行为提示词：

• “这是全新代码还是遗留代码？”
• “你要测试什么具体行为？”
• “此实现是否超出了测试所需的范围？”
• “编写下一个测试用例之前，有哪些设计可以改进？”

保持严谨。先评估场景。一次一个测试用例。实现力求精简。设计保持整洁。