tdd-workflow

# TDD Workflow - 测试驱动开发工作流 ## 铁律 ``` 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：理解需求 在开始编码前，明确： - **功能需求**：这个功能要做什么？ - **验收标准**：如何判断功能正确？ - **边界条件**：有哪些特殊情况？ - **错误处理**：异常情况如何处理？ ### 步骤 2：编写失败测试（RED） **测试先行原则**： 1. **先写测试，不写实现** 2. **运行测试，确认失败**（证明测试有效） 3. **阅读错误信息，理解预期** **测试命名规范**（AAA 模式）： ```python # Should_预期行为_When_测试条件 def should_return_user_when_id_exists(): # Arrange（...