系列文章目录
文章目录
- 系列文章目录
- 前言
- [一、什么是 TDD](#一、什么是 TDD)
- [二、TDD 的适用场景](#二、TDD 的适用场景)
- [三、TDD 如何实现](#三、TDD 如何实现)
-
-
- [🔴 Step 1：RED（写失败测试）](#🔴 Step 1：RED（写失败测试）)
- [🟢 Step 2：GREEN（写最小实现）](#🟢 Step 2：GREEN（写最小实现）)
- [🔵 Step 3：REFACTOR（重构）](#🔵 Step 3：REFACTOR（重构）)
-
- 总结
前言
现在大家都在使用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 时代的本质价值：
- 控制生成过程
AI 不再一次性生成大段代码
被迫小步推进 - 防止自证正确
测试先于实现，避免"围绕代码写测试" - 控制上下文增长
二、TDD 的适用场景
TDD 并不是"一刀切"的，而是应该按复杂度使用：
🟢 小需求（工具函数 / 脚本）
建议：先写代码，再简单验证，原因是TDD 成本 > 收益
🟡 中等需求（模块 / 接口）
例如：API 接口，业务逻辑模块
建议：核心路径使用 TDD，边缘逻辑可放宽
🔴 复杂系统（核心业务 / 多模块）
例如：交易系统，权限系统，Agent 框架
建议：严格 TDD，因为一旦出错，代价极高
TDD的优点是：
- 强约束 AI 行为
- 提高系统稳定性
- 降低长期成本
- 提升可维护性
缺点是：
- 认知成本高
- 开发节奏变慢（短期）
- token 成本增加（AI 特有）
- 工程复杂度提升
三、TDD 如何实现
以"实现用户登录校验"为例：
🔴 Step 1：RED（写失败测试）
text
目标：定义行为操作：
-
在
tests/中写测试：- 正确登录
- 密码错误
- 用户不存在
-
运行测试：
text
结果：失败（必须失败）🟢 Step 2：GREEN（写最小实现）
text
目标：让测试通过操作：
- 在
src/写最小代码 - 再次运行测试
text
结果：全部通过注意：
❗ 只写"刚好通过"的代码，不做优化
🔵 Step 3：REFACTOR（重构）
text
目标：优化代码结构操作：
- 重构逻辑
- 提取函数
- 优化命名
前提：
text
所有测试必须仍然通过总结
AI Coding 时代，代码很便宜，但"正确性"变得昂贵，而 TDD 是控制正确性的核心手段。小需求，直接写测试用例即可，但是重要的中大型需求，就需要TDD。