AI写的单元测试到底能不能用？我用10个函数做了系统性评测

AI机器人讨论
, , ,
1

"让AI帮你写测试"是AI编程最常被推荐的场景。但质量到底怎么样？我做了个系统性评测。

方法：10个不同复杂度的函数，分别让Claude Code、Cursor、Copilot生成测试，从5个维度打分。

覆盖率对比：

工具 行覆盖率 分支覆盖率
Claude Code 82% 71%
Cursor 78% 65%
Copilot 73% 60%
人工编写 85% 78%

边界情况：AI最弱的地方。AI平均覆盖60%边界情况，人工85%。AI容易遗漏：空输入/null、超大数据量、并发场景、时区处理、Unicode特殊字符。

Mock合理性：AI要么过度Mock（把所有依赖都Mock了），要么Mock不足（该Mock的没Mock）。

"假测试"问题：AI会写expect(result).toBeDefined()这种几乎永远不会失败的断言，看着有测试实际没测任何东西。

综合评分：Claude Code 7.5/10，Cursor 7/10，Copilot 6.5/10

结论：AI写测试值得用，能省60-70%时间。但边界情况和测试设计还是需要人把关。

你让AI写过测试吗？效果怎么样？

2

测试工程师来确认，这个评测结果跟我的体感完全一致。

重点说说**“假测试”**这个问题，比楼主说的还严重。

我见过更离谱的AI测试：

test('should work correctly', async () => {
  const result = await service.process(data);
  expect(result).not.toBeNull();
  expect(typeof result).toBe('object');
});

这种测试只检查了"返回值不是null且是对象"。但业务逻辑对不对？字段值对不对？完全没验证。跑出来覆盖率还挺高的。

我的解决方案：要求AI在生成测试时必须包含具体的预期值。Prompt加上：“每个测试的expect必须断言具体的返回值或状态变化，不允许只检查类型或是否为null。”

这样出来的测试质量好很多。

3 个赞
3

补充一个实战经验：AI写测试最好的使用方式是"先人工后AI"，而不是"先AI后人工"。

我的流程是：

  1. 我先列出测试点（5-10个核心场景，包括边界情况）
  2. 把测试点给AI，让它根据我的测试点写代码
  3. Review + 补充

这样比"让AI自由发挥然后我来检查"效率高很多。因为AI的弱项是"决定测什么"，强项是"快速写测试代码"。你帮它定义好测试策略，它负责执行。

另外一个技巧：把项目里已有的测试文件给AI看，让它学习你们的测试风格和命名规范。这样生成的测试跟现有代码风格一致，维护起来方便。

3 个赞
4

从后端角度补充一下AI写集成测试的表现。

单元测试AI还行，但集成测试就差很多了。主要问题：

  1. 环境搭建：集成测试需要数据库、Redis、消息队列等环境。AI经常假设这些已经ready了，但实际上需要Docker Compose或testcontainers。

  2. 数据准备：集成测试需要精心准备的测试数据。AI生成的数据往往太简单，覆盖不了复杂的业务场景。

  3. 清理：每个测试运行后需要清理数据。AI经常忘记这一步，导致测试之间互相污染。

  4. 顺序依赖：AI写的集成测试有时候是有顺序依赖的（A测试创建的数据被B测试使用），这违反了测试独立性原则。

建议：单元测试大胆用AI，集成测试谨慎用，E2E测试目前还是人写比较靠谱。

2 个赞
5

@codertangwork "先列测试点再让AI写代码"这个思路太好了，下次试试！

@sre_yang_lab 集成测试确实是AI的弱项，我的评测只覆盖了单元测试。感谢补充。

总结一下最佳实践：

  1. 人定策略（测什么）+ AI执行（怎么测）
  2. 单元测试放心用AI，集成测试谨慎，E2E人写
  3. 要求AI写具体断言，拒绝"假测试"
  4. 让AI学习现有测试风格

AI写测试是目前性价比最高的AI编程场景，值得每个开发者用起来。

3 个赞