tdd-workflowlisted

# TDD Workflow - 测试驱动开发工作流 ## 与 bensz-collect-bugs 的协作约定 - 因本 skill 设计缺陷导致的 bug，先用 `bensz-collect-bugs` 规范记录到 `~/.bensz-skills/bugs/`，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。 - 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 `gh` 上传新增 bug 到 `huangwb8/bensz-bugs`；不要 pull / clone 整个仓库。 ## 铁律 ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` **违反规则的信件就是违反规则的精神。** **无例外**： - 不保留为"参考" - 写测试时"不调整" - 不看它 - 删除=删除 --- ## 常见合理化 | 借口 | 现实 | |------|------| | "太简单不需要测试" | 简单代码也会坏。测试只需 30 秒 | | "我之后再测试" | 测试立即通过证明不了什么 | | "测试后达到相同目的" | 测试后="代码做什么?"测试前="代码应该做什么?" | | "已经手动测试了" | 临时≠系统化。无记录，无法重新运行 | | "删除 X 小时工作是浪费" | 沉没成本谬误。保留未验证代码是技术债 | | "保留参考，先写测试" | 你会调整它。那是测试后。删除=删除 | --- ## 红色标志 - 停止并重新开始 - 测试前有代码 - "已经手动测试了" - "测试后达到相同目的" - "是精神而非仪式" - "只此一次"的合理化 - "保留为参考" - 写测试时"不调整" **所有这些意味着：删除代码。用 TDD 重新开始。** --- ## 核心理念 **测试驱动开发（Test-Driven Development, TDD）** 是一种先编写测试，再编写实现代码的开发方法。通过严格的 **Red-Green-Refactor** 循环，确保代码质量和可维护性。 ### TDD 循环 ``` ┌─────────────────────────────────────────────────────────┐ │ 1. RED : 编写失败的测试 │ │ 2. GREEN : 编写最简单的代码使测试通过 │ │ 3. REFACTOR: 在测试保护下重构代码 │ │ 4. 重复循环 │ └─────────────────────────────────────────────────────────┘ ``` --- ## 何时使用本技能 在以下场景时激活： - 用户明确要求使用 **TDD** 或 **测试驱动开发** - 需要编写新功能或修复 Bug - 提到"测试"、"��元测试"、"测试覆盖率" - 需要确保代码质量 - 重构现有代码（先补充测试） --- ## TDD 工作流程 ### 步骤 1：理解需求 在开始编码前，明确： - **功能需求**：这个功能要做什么