用 AI 写单元测试，我踩过的坑和现在的做法
-
AI 写单元测试确实快，但我踩过一个很典型的坑：它很容易写出“看起来覆盖了，其实什么也没防住”的测试。
最常见的情况是，它把实现逻辑又抄了一遍。代码怎么写，它测试就怎么断言。这样测试当然能过，但一旦实现本身有 bug，测试也跟着错。
我现在给 AI 写测试时，会把要求说得更具体：
- 不要复述实现，测用户能观察到的行为
- 至少覆盖一个正常输入、一个边界输入、一个错误输入
- 如果函数依赖外部服务，优先 mock 边界，不要 mock 掉真正要测的逻辑
- 测试名要像一句说明，而不是 test case 1
还有个办法很有效：先让 AI 列测试用例，不让它写代码。你先看用例是否靠谱，再让它补测试。这样能避免它直接冲进实现细节。
AI 写测试最适合的不是“替我保证质量”，而是“帮我把我已经想清楚的质量标准快速落地”。这两件事差别很大。
你们有遇到过那种全部绿灯、上线照样炸的 AI 测试吗？
-
AI 写单元测试确实快，但我踩过一个很典型的坑：它很容易写出“看起来覆盖了，其实什么也没防住”的测试。
最常见的情况是，它把实现逻辑又抄了一遍。代码怎么写，它测试就怎么断言。这样测试当然能过，但一旦实现本身有 bug，测试也跟着错。
我现在给 AI 写测试时，会把要求说得更具体：
- 不要复述实现，测用户能观察到的行为
- 至少覆盖一个正常输入、一个边界输入、一个错误输入
- 如果函数依赖外部服务，优先 mock 边界，不要 mock 掉真正要测的逻辑
- 测试名要像一句说明，而不是 test case 1
还有个办法很有效：先让 AI 列测试用例，不让它写代码。你先看用例是否靠谱，再让它补测试。这样能避免它直接冲进实现细节。
AI 写测试最适合的不是“替我保证质量”，而是“帮我把我已经想清楚的质量标准快速落地”。这两件事差别很大。
你们有遇到过那种全部绿灯、上线照样炸的 AI 测试吗？