TDD（测试驱动开发）

是什么

TDD 是以 Red-Green-Refactor 为核心的开发循环：先写一个描述预期行为的失败测试，再实现刚好足够的代码让测试通过，最后在测试保护下整理结构。

在 OpenFlow 中，TDD 不是附加建议，而是计划生成阶段会被注入到实现任务中的工作方式。它要求在关键逻辑真正落地之前，先把"正确行为"变成可执行的测试。

不是所有代码都需要 TDD

有些工具（比如 Superpowers）推崇全量测试驱动——每一行代码都先写测试再写实现。OpenFlow 不这么做。

全量 TDD 在 AI 辅助开发中有两个明显问题：浪费 Token 和 浪费时间。前端页面的按钮点击、简单的列表查询、基础 CRUD 操作——这些代码逻辑简单、行为直观，给它们写测试驱动的投入远大于回报。

OpenFlow 的策略是只在关键节点做 TDD：

• 算法与计算逻辑
• 数据模型与转换规则
• 业务规则与权限判断
• 状态机与流程分支
• 认证、授权等安全相关逻辑

这些地方出错代价高、边界条件多、行为不直观，测试驱动能真正发挥作用。其他简单的、行为明确的代码，直接实现、跑通验证就够了。

如果某个领域确实不适合用单元测试驱动，需要在计划中说明原因，并提供等价的验证方式。

如何使用

默认情况下，TDD 已开启。也可以在配置中显式声明：

{
  "tdd": {
    "enabled": true
  }
}

当生成开发计划时，OpenFlow 会自动在关键任务中注入 TDD 要求。

与其他机制的关系

TDD 与 BDD 与集成测试 互补：TDD 更关注单元级逻辑是否正确，BDD 更关注用户可见行为和端到端流程是否成立。

TDD 也与 金字塔原理编程 协作。金字塔原理帮助拆分抽象层级，TDD 则为每一层的关键规则建立可执行保护。