系列文章目录

---

---

前言

现在大家都在使用ai写代码，手写代码的时代慢慢过去了，但是现在有一个问题，就是如何判断ai写的代码有效，这就离不开测试用例。那么应该先写代码，还是应该先写测试用例呢，今天主要说下TDD。

---

一、什么是 TDD

TDD（Test-Driven Development，测试驱动开发）是一种开发方法，其核心流程是：

RED → GREEN → REFACTOR

• RED：先写测试（且必须失败）
• GREEN：写最小实现让测试通过
• REFACTOR：在测试保护下优化代码

这里最重要的一点是：
测试不是验证代码，而是定义需求（Test = Specification）

AI Coding 时代的问题：
1、实现偏置（Implementation Bias）
AI 天生倾向于：先写完整代码，再写“证明自己正确”的测试，这导致：测试只是“自证正确”，而不是验证需求。

2、一次性生成过多代码
AI 很容易：一次生成几百行代码，引入隐藏 bug，难以局部修复

3、上下文污染（Context Pollution）

TDD 在 AI 时代的本质价值：

1. 控制生成过程
   AI 不再一次性生成大段代码
   被迫小步推进
2. 防止自证正确
   测试先于实现，避免“围绕代码写测试”
3. 控制上下文增长

二、TDD 的适用场景

TDD 并不是“一刀切”的，而是应该按复杂度使用：
🟢 小需求（工具函数 / 脚本）
建议：先写代码，再简单验证，原因是TDD 成本 > 收益

🟡 中等需求（模块 / 接口）
例如：API 接口，业务逻辑模块
建议：核心路径使用 TDD，边缘逻辑可放宽

🔴 复杂系统（核心业务 / 多模块）
例如：交易系统，权限系统，Agent 框架
建议：严格 TDD，因为一旦出错，代价极高

TDD的优点是：

1. 强约束 AI 行为
2. 提高系统稳定性
3. 降低长期成本
4. 提升可维护性

缺点是：

1. 认知成本高
2. 开发节奏变慢（短期）
3. token 成本增加（AI 特有）
4. 工程复杂度提升

三、TDD 如何实现

以“实现用户登录校验”为例：

🔴 Step 1：RED（写失败测试）

目标：定义行为

操作：

1. 在 tests/ 中写测试：

   • 正确登录
   • 密码错误
   • 用户不存在

2. 运行测试：

结果：失败（必须失败）

---

🟢 Step 2：GREEN（写最小实现）

目标：让测试通过

操作：

1. 在 src/ 写最小代码
2. 再次运行测试

结果：全部通过

注意：

❗ 只写“刚好通过”的代码，不做优化

---

🔵 Step 3：REFACTOR（重构）

目标：优化代码结构

操作：

• 重构逻辑
• 提取函数
• 优化命名

前提：

所有测试必须仍然通过

---

总结

AI Coding 时代，代码很便宜，但“正确性”变得昂贵，而 TDD 是控制正确性的核心手段。小需求，直接写测试用例即可，但是重要的中大型需求，就需要TDD。

参考文档1，2