GitHub Copilot 写单元测试最省时间的一步，是把第一版代码生成出来。真正决定这些测试能不能进入代码库的，却是后面的检查：断言有没有碰到业务规则，Mock 是否对应当前依赖，异常分支是不是真的会失败。
GitHub 官方教程用 Python 的 BankAccount 类演示如何通过 Copilot Chat 生成单元测试；Microsoft 的快速入门则把场景放到 Java 和 Visual Studio Code 中，流程包括创建测试项目、生成代码并实际运行。
这些示例说明 Copilot 很适合起稿。但“生成完成”和“测试可信”，中间还隔着一次认真验收。
它快在样板，不快在判断
面对结构清楚的类或函数，Copilot 通常能迅速补出测试函数、初始化代码以及基础输入场景。项目里已有测试目录、fixture 和辅助函数时，它也更容易沿用现成写法。
关键是控制上下文。一篇关于生成单元测试的实践文章建议先高亮需要测试的代码，再通过斜杠命令生成测试。这个动作看似简单，却能减少无关代码对结果的干扰。
不要一次把整个服务层都交给 Copilot。选中一个方法，明确一个场景，生成结果更容易读，也更容易删。上下文给得太宽，测试可能混入无关依赖，甚至引用项目里不存在的方法或返回结构。
覆盖了代码，不等于验证了行为
行覆盖率回答的是“这行代码有没有执行”，不是“业务结果有没有被正确检查”。一个测试可以顺利调用目标方法，只断言 result is not None，然后把关键状态变化和错误条件全部漏掉。
以账户类为例，执行方法只是第一步。测试还要确认可观察结果是否符合规则，以及输入不合法、依赖失败时是否进入正确分支。否则代码虽然被跑过，真正出错时用例仍可能保持绿色。
审查 AI 生成的测试，可以先问三个问题：
- 如果实现返回了错误结果，这条测试会失败吗？
- Mock 模拟的是项目真实依赖，还是一个过于理想的响应？
- 测试名称能否说清业务条件和预期结果？
如果答案含糊，这条测试就不该因为提升了覆盖率而被保留。
真正花时间的，是生成之后
Copilot 的生成速度很直观，后续成本却分散在代码审查、调试和维护里。生成后最值得检查的，不是格式，而是下面几项：
| 检查项 | 容易留下的问题 | 处理方式 |
|---|---|---|
| 断言 | 只检查非空、无异常或调用次数 | 改为检查状态变化、返回结果或明确的异常类型 |
| Mock | 方法名、参数或返回结构与当前依赖不一致 | 对照项目代码和正在使用的 SDK 核验 |
| 边界场景 | 只有正常输入，没有空值、超时或权限失效 | 先列场景，再逐条生成 |
| 可维护性 | 命名含糊、初始化代码重复、用例互相重叠 | 复用 fixture，删除没有新增验证内容的测试 |
这些工作不会体现在点击生成按钮的那一刻，却会直接影响团队以后改代码的难度。生成十条相似测试并不难，难的是业务规则变化后，开发者还要逐条判断哪些应该修改、哪些本来就没有保留价值。
先写边界，再让 Copilot 补代码
更稳的工作流不是“生成一批再挑”，而是先由开发者规定测试目标。
先选中最小范围的目标代码，再用注释写清条件和预期结果。例如：输入为空、依赖超时、凭证失效。随后一次只生成一个场景，并要求 Copilot 复用项目现有的 fixture 和 Mock。
提示词不需要写得很长，但要限制任务边界：
为选中的 Python 方法补一个 pytest 用例，只覆盖“依赖超时”。
复用项目现有 fixture，不创建不存在的接口。
断言异常类型和可观察结果，不要只检查函数被调用。
代码生成后应立即在真实项目中运行，而不是等整批测试写完再统一处理。Microsoft 的 Java 快速入门同样把创建测试、生成代码和运行测试放在一条流程里。运行失败可以及时暴露依赖、导入和测试框架配置问题；运行成功后，还要再看断言是否足够严格。
条件允许时，也可以用变异测试检查这些用例。对业务代码做一个小改动，如果测试仍然全部通过，就要回头检查断言，而不是直接把这次运行记作成功。
团队指标也要换个问法
GitHub 面向企业推广 Copilot 的测试覆盖率指南建议先定义目标，再围绕目标规划推广方式和指标。覆盖率可以继续看，但不适合单独作为验收结论。
团队还需要确认：新测试是否对应明确的业务行为，错误实现能否让它失败，生成代码是否沿用了现有测试设施，重复和不稳定的用例有没有及时清理。
Copilot 最合适的位置，是单元测试的第一稿作者。它可以补样板、搭结构、展开已经定义好的场景；边界由谁确定、断言是否有效、Mock 是否可信，仍然需要开发者判断。
生成得快当然有用。但只有能抓住错误行为的测试，才是代码资产。其余部分，无论让覆盖率数字多好看，最后都会变成维护负担。
