这篇写给已经会用 AI 写单元测试、希望再进一步的读者。理解原理是关键：写测试需要系统地思考各种输入情况，这正是 AI 擅长列举的部分；你再根据业务判断取舍，就能更快地得到质量较高的测试。

AI 写测试的意外收获，往往是发现代码本身的问题。当它列出“如果输入为空会怎样”“如果两个参数相等会怎样”时，你可能会发现自己从没考虑过这些情况。所以用例清单阶段比生成代码阶段更有价值：认真看清单，才能真正提升代码质量。

技巧 1：先让 AI 列用例清单

先让 AI 列用例清单，确认后再写代码，效率更高。这能帮你更快定位问题出在哪个环节。

技巧 2：让 AI 专门寻找“最可能出错的输入”

让 AI 专门寻找“最可能出错的输入”适合在任务较复杂或要反复使用时采用。

技巧 3：对重构前的代码

对重构前的代码，先写测试记录当前行为。这能帮你更快定位问题出在哪个环节。

技巧 4：测试数据使用虚构数据

测试数据使用虚构数据，不要用真实的用户信息。做到这一点，结果的稳定性会明显提高。

技巧 5：把测试用例清单作为文档

把测试用例清单作为文档，帮助其他人理解函数的行为。建议先在一个小任务上试用，确认效果后再推广。

一个进阶场景

举个虚构的例子：一位测试工程师接手一个没有测试的旧模块，需要在重构前补齐测试。她把模块代码交给 AI，先生成用例清单，和开发同事一起确认哪些是预期行为、哪些其实是缺陷。最终补齐了 40 多个测试用例，重构时有两个测试失败，及时发现了被意外改变的行为。

老代码没有文档怎么写测试？ 可以先让 AI 解释代码行为，你确认后再基于当前行为写测试。

一份进阶写法

下面的模板综合了以上技巧，可以按财务等不同场景替换内容：

测试质量检查：
1. 覆盖：每个分支和错误处理路径是否都有测试？
2. 独立：测试之间是否互相依赖？是否依赖外部服务（需要模拟）？
3. 断言：是否断言了具体的结果，而不只是“没有报错”？
4. 可读：测试名称是否说明了场景和预期？
5. 稳定：是否依赖当前时间、随机数等不稳定因素？
6. 价值：有没有测试只是在重复实现细节，重构时容易失效？
请对以下测试代码逐项检查并给出改进建议：[粘贴]

进阶使用时仍要避免

  • ✗ 测试失败就修改测试让它通过。 ✓ 先判断是代码错误还是测试错误。
  • ✗ 测试依赖外部服务。 ✓ 使用模拟对象，保证测试稳定可重复。

可以组合的技能

  • AI 编程助手：AI 编程助手是集成在代码编辑器或开发环境中的 AI 功能，能补全代码、解释代码、根据注释生成函数、重构、写测试，部分工具还能在理解整个项目的基础上执行多文件修改。
  • AI 代码审查：AI 代码审查是让 AI 在人工评审之前或同时，检查代码中的潜在问题：逻辑错误、边界情况、安全隐患、性能问题、可读性和风格不一致，并给出具体的修改建议。

衡量是否真的进步

一个简单的标准：同类任务需要的修改轮次是否减少，结果是否更稳定。如果答案是肯定的，说明你的 AI 写单元测试已经进阶；如果没有，回到基础步骤检查哪里写得不够具体。

相关阅读