本指南受 GitHub 的 工程系统成功手册（ESSP）启发，手册建议用于推动工程系统改进的策略和指标。
如果您正准备在公司推广 Copilot，我们建议先定义目标，相应地规划推广计划，并向员工清晰传达目标。请参阅 使用 GitHub Copilot 实现公司工程目标。
1. 确定成功的障碍
ESSP 推荐的第一步是清晰了解阻碍公司改进的障碍。通过了解您当前的基准、期望的未来状态以及阻止进展的障碍，您可以确保变更具针对性且有效。
许多软件团队因单元测试覆盖率低而面临持续的高质量代码维护挑战。在快节奏的开发环境中，编写测试常被视为耗时或非必要，尤其是在团队面临快速交付功能的压力时。
结果，关键缺陷可能在开发生命周期后期才被发现，往往出现在预发布或生产环境中。
这导致了一连串负面结果
- 更高的缺陷率 和客户报告的问题
- 更高的成本 用于修复部署后的缺陷
- 降低的开发者信心 对其代码稳定性的信心
- 更慢的发布周期 由于被动调试和补丁导致
在遗留系统中，测试覆盖率更难以提升，因为存在复杂的依赖或文档不完善的代码。开发者可能对旧代码库或测试框架缺乏熟悉度，进一步加剧了问题。
提升测试覆盖率是公认的最佳实践，但它需要时间和专业知识，而许多团队难以分配这些资源。
2. 评估您的选项
下一步是评估并确定解决第一步中识别的障碍的方案。在本指南中，我们将聚焦于 GitHub Copilot 对您已确定目标的影响。成功推广新工具还需要文化和流程的变更。
在试点小组中对新工具和流程进行试验，以收集反馈并衡量成功。有关培训资源和试验期间使用的指标，请参阅 3. 实施变更 与 需要关注的指标 部分。
Copilot 如何提供帮助
GitHub Copilot 可以显著加速并简化编写单元测试的过程。通过理解周围的代码和上下文，Copilot 能够建议与被测代码结构和逻辑相匹配的测试函数。
Copilot 的能力在多种场景中都有用
- 当开发者编写新函数时，Copilot 能自动在行内建议相应的测试用例。
- 在重构遗留代码时，Copilot 可以帮助生成测试脚手架以防止回归。
- 对于未测试的模块，开发者可以提示 Copilot 生成有意义的测试用例，即使测试覆盖率缺失或不一致。
通过让单元测试更容易、更快速且更少手动操作，Copilot 减少了导致测试覆盖率空白的阻力，帮助团队采用质量第一的思维方式。
使用场景
- 行内测试生成: 开发者可以请求 Copilot 为特定函数或模块生成测试，而无需切换上下文。
- 更好的边缘案例覆盖: 通过提示 Copilot 边缘场景（如空输入、空列表或无效状态），开发者可以快速覆盖更多逻辑分支。
- 加速入职: 新成员可以通过查看生成的测试用例，利用 Copilot 了解函数的预期行为。
- CI/CD 支持: Copilot 可以建议如何将测试集成到构建流水线中，确保覆盖率的提升直接支持质量门槛。
文化考虑
在推广 GitHub Copilot 的同时，需解决可能阻碍实现目标的任何社交或文化因素。
以下示例摘自 ESSP 中的“反模式”章节。
- 团队可能 依赖手动测试 或自动化测试不足。这可能是由于自动化资源受限或缺乏现代测试工具经验造成的。
- 团队可能 等待发布时间过长，一次性部署大量代码，这使得缺陷和回归更难被发现。这可能是由于 CI/CD 流水线不成熟、严格的合规要求或在 PR 与部署之间的审查周期过长导致的。
3. 实施变更
当您确定了解决障碍的正确方法后，就可以扩大这些方案的规模。要成功推广新工具或流程，请为每个环节指定负责人，透明沟通目标，提供有效培训，并衡量结果。
本节提供示例情景、最佳实践和面向开发者的资源。请利用本节 规划沟通和培训会议，帮助员工以符合您目标的方式使用 Copilot。
行内生成测试
- 在 VS Code 中，选择要测试的函数并提示 Copilot：
为此代码生成单元测试。 - Copilot 会根据语言和结构，在行内或单独的测试文件中生成测试。
- 审查、完善并接受建议。
覆盖边缘情况
-
编写测试后，询问 Copilot：
我应该为此函数测试哪些边缘情况？或：
为输入为 null 或空的情况编写测试用例。 -
Copilot 会建议额外的测试用例以覆盖边界条件。
-
审查这些测试并将其纳入测试套件。
了解新代码
- 选择一个遗留函数并询问 Copilot：
解释此函数的作用并生成验证它的测试。 - Copilot 解释函数的目的并建议相应的测试用例。
- 查看测试用例以了解预期行为并快速构建上下文。
获取 CI/CD 支持
- 审查你的测试用例并提交到代码库。
- 询问 Copilot：
如果想让此测试在 CI 中运行，我应该把它放在哪里？ - Copilot 将根据代码库结构，建议放置测试文件的位置以及如何更新流水线配置。
开发者最佳实践
开发者 应当
- 在与 Copilot 对话时使用描述性评论或提示。例如：
为根据用户类型和购买金额计算折扣的函数生成单元测试。 - 使用 Copilot 探索逻辑覆盖。例如：
此函数有哪些分支或条件需要测试？ - 探索不同的提示技巧并比较不同 AI 模型的结果。
开发者 不应
- 接受生成的测试而不审查逻辑。确保测试反映实际需求并处理真实的输入输出。
- 跳过对边缘行为的断言。如果只测试“成功路径”，可能会错过回归。
- 依赖 Copilot 猜测未文档化的业务规则。务必通过提示或注释提供上下文。
- 将 Copilot 视为人类代码审查的替代品。Copilot 能加速过程，但仍需运用工程判断。
开发者资源
- 使用 GitHub Copilot 编写测试
- 如何使用 GitHub Copilot 生成单元测试：技巧与示例
- GitHub Copilot 在 Visual Studio 中无处不在（包含测试章节的视频内容）
- GitHub Copilot Chat 的提示词工程
- 更改 GitHub Copilot Chat 的 AI 模型
推荐功能
需要关注的指标
为评估新工具的试点并确保全面推广带来持续改进，请监控结果并在需要时进行调整。我们建议关注 质量、交付速度和开发者满意度 三大维度，以及它们如何共同推动业务成果。
以下是评估 Copilot 对该特定目标影响的部分指标。
- 测试覆盖率: 在采用 Copilot 后追踪行覆盖率和分支覆盖率的提升。如可能，查看 CI 流水线的测试覆盖率报告。
- 部署后的缺陷率: 生产环境中报告的缺陷应更少。
- 开发者信心: 使用调查或回顾评估开发者对交付新代码的信心程度。
- 编写测试的时间: 衡量创建单元测试所花时间的减少。