AI Coding 时代的 TDD：从理念到工程落地

系列文章目录

文章目录

系列文章目录
前言
[一、什么是 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。

参考文档1，2