前言

🍊AI 都会写代码了，为什么还要学 TDD

开发组长在会上说：

TDD 测试驱动开发，开发以后都得加入。

第一反应多半是：AI 都会写代码了，怎么还要先学写测试？

假设你只告诉 AI“写一个满减功能”，它并不知道刚好 100 元减不减，优惠后能不能小于 0，输入负数是返回 0 还是直接报错。

AI 可以替你写代码，却不能替你决定业务规则。写得快归快，规则没说清楚，代码怪容易跑偏。

测试能把这些细节变成可执行的验收标准。AI 每改一次代码，都要按同一套标准重新检查。TDD 在 AI 开发中的价值，就藏在这个过程里。

正文

🎯TDD 到底是什么

TDD 全称 Test-Driven Development，中文叫测试驱动开发。

过程就三步，咱慢慢看：

👽 人话解释

先定好答案，再开始写代码。测试通过后可以整理实现，但别偷偷改掉验收标准。

普通开发先想“我要怎么实现”，TDD 先问“这个功能应该表现出什么行为”。

🍪用购物车满减跑一遍

需求如下：

购物车原价达到 100 元时优惠 20 元，不足 100 元不优惠。

技术栈使用 Java 和 JUnit 5。先列出三个测试：

[ ] 80 元不优惠
[ ] 100 元优惠 20 元
[ ] 负数金额直接报错

第一步：先亮红灯

class PriceCalculatorTest {

    private final PriceCalculator calculator = new PriceCalculator();

    @Test
    void shouldKeepOriginalPriceWhenAmountIsBelow100() {
        int result = calculator.calculate(80);

        assertEquals(80, result);
    }
}

此时 PriceCalculator 还不存在，测试当然会失败。甭怕这个红灯，它证明测试确实碰到了尚未实现的功能。如果新测试第一次运行就是绿色，先看看它是不是真的测到了东西。

第二步：用最少代码变绿

class PriceCalculator {

    int calculate(int amount) {
        return amount;
    }
}

测试通过后，再增加“满 100 减 20”：

@Test
void shouldDiscount20WhenAmountReaches100() {
    assertEquals(80, calculator.calculate(100));
}

测试会得到 100，再次变红。修改实现：

int calculate(int amount) {
    if (amount >= 100) {
        return amount - 20;
    }
    return amount;
}

重新运行，两个测试都通过。旧测试也要保持绿色，这样才能确认新需求没有破坏原有功能。

第三步：补异常，再重构

负数金额应该报错：

@Test
void shouldRejectNegativeAmount() {
    assertThrows(
        IllegalArgumentException.class,
        () -> calculator.calculate(-1)
    );
}

最终实现可以整理成这样：

class PriceCalculator {

    private static final int THRESHOLD = 100;
    private static final int DISCOUNT = 20;

    int calculate(int amount) {
        if (amount < 0) {
            throw new IllegalArgumentException("amount must not be negative");
        }
        return amount >= THRESHOLD ? amount - DISCOUNT : amount;
    }
}

最后运行全部测试。只要还是绿色，这次重构就没有改坏原有行为。一轮 TDD 到这里就跑完了。

🤖为什么 TDD 适合 AI 编程

一.AI 需要明确的完成标准

“功能正常”“注意边界”“代码健壮”，这些要求对 AI 来说太模糊。测试把输入、输出和异常写死，AI 跑完就知道哪里没过。

但测试通过只代表已写下来的规则得到满足。漏掉的规则，测试同样看不见，所以人仍然要审核业务边界。

二.AI 改得越快，越需要回归检查

人工一次改十行，还能逐行看看。AI 一次改十个文件，单靠肉眼很难发现旧功能是否被碰坏。

可以把工作分成四步：

人：定义目标和边界
AI：生成或修改代码
测试：反复执行验收规则
人：检查遗漏，决定是否合并

AI 把实现速度提上去，测试负责及时报错，最后仍由人决定能不能合并。

三.TDD 能把大需求拆成小步

一上来就说“帮我开发一套电商优惠系统”，范围太大。

“先让满 100 减 20 的测试通过，别改其他规则”就清楚得多。

TDD 每次只推进一个行为，哪一步跑偏了，很快就能发现。

测试和实现如果都交给 AI 一次生成，也可能出现彼此迁就的情况。审查时重点看三处：测试有没有真实失败过，失败原因对不对，关键业务边界有没有覆盖。

⚠️初学者最容易踩的坑

1.为了变绿，反过来改测试

需求要求返回 80，实现却返回 90。应该修改实现，不能把断言改成 90。只有业务规则真的变了，测试才能跟着变。

2.测试内部实现

尽量测试输入、输出、状态和异常。少盯着私有方法调用了几次，否则代码稍微重构，测试就碎一地。

3.只顾红和绿，忘了重构

测试通过只说明功能暂时正确，不代表代码清楚。重复逻辑、含糊命名和过长方法，都应该在绿灯后及时整理。

🧭TDD 不用到处硬套

初学者可以先拿金额计算、参数校验、数据格式转换，以及能稳定复现的 Bug 练手。这些功能输入输出明确，测试也跑得快。

频繁试错的界面原型、强依赖视觉效果的页面或一次性脚本，不必强行套用纯 TDD。可以根据风险选择集成测试、端到端测试或人工验收。

甭把 TDD 当成必须遵守的仪式。能缩短反馈、降低风险时就用，不合适就换别的办法。

🚀让 AI 按 TDD 工作

下次可以把这段提示词交给 AI：

请按 TDD 完成这个需求：
1. 先列测试清单，一次只实现一个行为。
2. 先写测试并运行，说明它为什么失败。
3. 写让当前测试通过的最少实现。
4. 运行全部测试，确认没有回归。
5. 重构后再次运行全部测试。
6. 不要放宽正确的断言来迁就实现。

再补上测试命令、允许修改的目录和完成标准，AI 干活时就不容易跑偏。

总结

🍯最后说几句

开发组长说 TDD 是未来 AI 开发的趋势。换个更准确的说法：

AI 承担越来越多实现工作后，开发者必须更早给出可验证的规则。TDD 正是一套成熟、简单的方法。

先写一个能正确失败的测试，再写最少代码让它通过，最后在测试保护下重构。AI 可以加速实现，但什么才算正确，还是得由人来定。

甭急着改造整个项目。先找一个十几行的校验方法，写个失败测试，再让它变绿。

第一轮跑通，感觉还是挺杠赛来的，你也就算入门了。

🍈猜你想问

如何与狗哥联系进行探讨？

关注公众号【JavaDog程序狗】，回复【入群】或【加入】，一起聊技术、聊踩坑。