<![CDATA[用 AI 写单元测试，我踩过的坑和现在的做法]]>AI 写单元测试确实快，但我踩过一个很典型的坑：它很容易写出“看起来覆盖了，其实什么也没防住”的测试。

最常见的情况是，它把实现逻辑又抄了一遍。代码怎么写，它测试就怎么断言。这样测试当然能过，但一旦实现本身有 bug，测试也跟着错。

我现在给 AI 写测试时，会把要求说得更具体：

  • 不要复述实现，测用户能观察到的行为
  • 至少覆盖一个正常输入、一个边界输入、一个错误输入
  • 如果函数依赖外部服务，优先 mock 边界，不要 mock 掉真正要测的逻辑
  • 测试名要像一句说明，而不是 test case 1

还有个办法很有效：先让 AI 列测试用例，不让它写代码。你先看用例是否靠谱，再让它补测试。这样能避免它直接冲进实现细节。

AI 写测试最适合的不是“替我保证质量”，而是“帮我把我已经想清楚的质量标准快速落地”。这两件事差别很大。

你们有遇到过那种全部绿灯、上线照样炸的 AI 测试吗？

]]>https://aspxai.com/topic/4/用-ai-写单元测试-我踩过的坑和现在的做法RSS for NodeWed, 17 Jun 2026 15:49:02 GMTWed, 17 Jun 2026 10:30:17 GMT60<![CDATA[Reply to 用 AI 写单元测试，我踩过的坑和现在的做法 on Wed, 17 Jun 2026 12:49:14 GMT]]>AI 写单元测试确实快，但我踩过一个很典型的坑：它很容易写出“看起来覆盖了，其实什么也没防住”的测试。

最常见的情况是，它把实现逻辑又抄了一遍。代码怎么写，它测试就怎么断言。这样测试当然能过，但一旦实现本身有 bug，测试也跟着错。

我现在给 AI 写测试时，会把要求说得更具体：

  • 不要复述实现，测用户能观察到的行为
  • 至少覆盖一个正常输入、一个边界输入、一个错误输入
  • 如果函数依赖外部服务，优先 mock 边界，不要 mock 掉真正要测的逻辑
  • 测试名要像一句说明，而不是 test case 1

还有个办法很有效：先让 AI 列测试用例，不让它写代码。你先看用例是否靠谱，再让它补测试。这样能避免它直接冲进实现细节。

AI 写测试最适合的不是“替我保证质量”，而是“帮我把我已经想清楚的质量标准快速落地”。这两件事差别很大。

你们有遇到过那种全部绿灯、上线照样炸的 AI 测试吗？

]]>https://aspxai.com/post/4https://aspxai.com/post/4Wed, 17 Jun 2026 12:49:14 GMT