系列文章：程序员 AI 效率笔记 | 第四篇

很多程序员不是不知道单元测试重要，而是觉得写测试太费时间。功能代码写完了，再补测试感觉是重复劳动；测试先行又不知道从哪里下手。AI 可以帮程序员快速生成测试框架、覆盖边界场景、补全测试用例，让写测试这件事变得不那么痛苦。

为什么程序员普遍不爱写测试

单元测试的重要性大家都知道，但实际项目里测试覆盖率往往很低。

原因通常有几个：

• 功能代码写完了，再写测试感觉是重复劳动

• 测试代码量有时候比功能代码还多

• 边界场景很多，想全覆盖很费时间

• 项目赶进度，测试是第一个被砍掉的

• 不知道怎么 mock 依赖，写起来很麻烦

结果就是：测试要么不写，要么只写几个最简单的 happy path，边界场景全靠手动测试。

AI 适合帮你做哪些测试工作

AI 在写测试这件事上，有几个比较实用的场景：

1. 根据函数签名生成测试框架

你把函数代码发给 AI，它可以快速生成测试文件的基本结构，包括测试类、测试方法命名、基本断言。

2. 补全边界场景

这是 AI 最有价值的地方。程序员写测试时容易只想到正常流程，AI 可以帮你列出：空值、零值、负数、超长字符串、并发、权限不足、数据不存在等边界情况。

3. 生成 mock 代码

依赖外部服务、数据库、第三方接口时，mock 代码写起来很繁琐。AI 可以根据接口定义快速生成 mock 对象和桩代码。

4. 把测试用例描述转成代码

你用自然语言描述测试场景，AI 帮你转成具体的测试代码。

5. 检查已有测试的覆盖盲点

把现有测试代码发给 AI，让它分析哪些场景没有覆盖到。

第一步：把函数代码发给 AI，让它生成测试框架

最简单的起点是直接把函数代码发给 AI。

比如你有一个计算库存调整后余量的函数：

public int adjustStock(int currentStock, int adjustAmount) {
    if (currentStock + adjustAmount < 0) {
        throw new IllegalArgumentException("库存不能为负数");
    }
    return currentStock + adjustAmount;
}

可以这样提示 AI：

请为下面的 Java 方法生成 JUnit 5 单元测试。
要求覆盖：正常调整、调整后为零、调整后为负数（应抛出异常）、调整量为零、大数值边界。
使用 @Test 和 assertThrows，不需要 mock。

AI 会生成包含多个测试方法的测试类，你只需要检查断言是否符合业务预期。

第二步：让 AI 列出边界场景清单

在写测试之前，可以先让 AI 帮你想边界场景，不用直接生成代码。

提示词示例：

我有一个用户登录接口，参数是用户名和密码，返回 token 或错误信息。
请列出所有需要测试的场景，包括正常流程和边界情况。
不需要写代码，只列场景描述。

AI 通常会列出：正确用户名和密码、用户名不存在、密码错误、用户名为空、密码为空、用户名超长、账号被锁定、并发登录、SQL 注入字符、特殊字符密码。

这个清单比你自己想要全面得多，然后你再根据实际业务规则筛选哪些需要写。

第三步：生成 mock 代码

测试里最麻烦的部分往往是 mock。

可以这样提示 AI：

我有一个 UserService，依赖 UserRepository 接口。
UserRepository 有 findByUsername(String username) 方法，返回 Optional<User>。
请用 Mockito 生成 UserService 的单元测试，测试用户不存在时抛出 UserNotFoundException 的场景。

AI 会生成完整的 mock 设置、方法调用和断言代码，你只需要确认异常类型和消息是否和你的代码一致。

第四步：检查 AI 生成的测试

AI 生成的测试代码不能直接用，需要检查：

1. 断言是否符合业务规则 — AI 不知道你的业务规定，它的断言可能是猜的

2. 测试数据是否合理 — AI 可能用无意义数据，有时候需要换成更接近真实场景的数据

3. mock 的行为是否正确 — 需要对照实际代码检查

4. 是否有重复测试 — AI 有时候会生成几个几乎一样的测试方法

5. 异常类型是否匹配 — AI 可能用通用的 Exception，但你的代码抛的是自定义异常

推荐工作流

1. 写完功能代码
2. 让 AI 列出测试场景清单
3. 人工筛选哪些场景需要覆盖
4. 让 AI 生成测试框架和 mock 代码
5. 人工检查断言和业务规则
6. 补充 AI 没想到的场景
7. 运行测试，修复失败用例
8. 检查覆盖率报告，补充遗漏分支

测试先行的场景怎么用 AI

如果你想做 TDD，AI 也可以帮上忙。

做法是先描述功能需求，让 AI 生成测试用例，再根据测试用例写功能代码。

提示词示例：

我要实现一个密码强度校验函数，规则如下：
- 长度至少 8 位
- 必须包含大写字母
- 必须包含数字
- 可选包含特殊字符，包含时强度更高
请先生成测试用例，不要写实现代码。

AI 会生成覆盖各种规则组合的测试用例，你再根据这些测试用例写实现代码。

需要注意的几个问题

• 不要把生产数据库连接信息发给 AI — 发给 AI 之前要先替换成占位符

• AI 不了解你的项目历史包袱 — 历史遗留问题需要你自己补充说明

• 测试通过不等于功能正确 — 断言写错了，测试通过也没有意义

• 覆盖率不是唯一目标 — 测试的质量比数量更重要

总结

程序员用 AI 写单元测试，最大的价值不是"自动生成测试代码"，而是降低写测试的启动成本，帮你想到更多边界场景。

合理的分工是：AI 负责生成框架和覆盖常见场景，程序员负责业务规则判断和断言验证。

如果能把这个流程跑顺，写测试这件事会比以前轻松很多。

---

程序员 AI 效率笔记系列，持续更新中。