本指南的灵感来自 GitHub 的工程系统成功 playbook (ESSP)，其中推荐了推动工程系统改进的策略和指标。
如果你要启动 Copilot 的推出，我们建议定义目标、相应地规划推出，并向员工明确传达目标。 请参阅“使用 GitHub Copilot 实现公司工程目标”。
1.确定阻碍成功的因素
ESSP 建议的第一步是充分了解阻碍公司取得进步的障碍。 通过了解当前的基线、所需的未来状态以及阻碍进步的障碍，可确保更改具有针对性且有效。
由于单元测试覆盖率较低，许多软件团队在维护高质量代码方面面临持续挑战。 在快节奏的开发环境中，编写测试通常被视为耗时或不必要，尤其是在团队面临快速交付功能的压力时。
因此，关键 bug 可能在开发生命周期的后期才被发现，通常是在过渡或生产环境中。
这会导致一系列负面结果：
- bug 率提高和客户报告的问题增加****
- 部署后修复 bug 的成本增加****
- 降低开发人员对其代码稳定性的信心****
- 反应式调试和修补导致发布周期变慢****
在旧系统中，由于复杂的依赖项或记录不佳的代码，测试覆盖率问题可能更难解决。 开发人员可能不熟悉较旧的代码库或一般测试框架，这进一步加剧了问题。
提高测试覆盖率是公认的最佳做法，但需要时间和专业知识，而许多团队无法满足这些要求。
2.评估你的选项
下一步是评估并商定解决方案，以解决在第一步中确定的障碍。 在本指南中，我们将重点关注 GitHub Copilot 对已确定目标的影响。 请记住，新工具的成功推出还需要文化和流程的变更。
你将与试点小组一起试用新工具和流程，以收集反馈并衡量成功与否。 有关试用期间使用的培训资源和指标，可提前查看 3.实施变更和要监视的指标部分。
Copilot 如何提供帮助
GitHub Copilot 可以显著加速和简化编写单元测试的过程。 通过了解周围的代码和上下文，Copilot 可以建议与所测试代码的结构和逻辑相匹配的测试函数。
Copilot 的功能在多个方案中非常有用：
- 当开发人员编写新函数时，Copilot 可以自动内联建议相应的测试用例。
- 重构旧代码时，Copilot 可以帮助生成测试基架以防止回归。
- 对于未经测试的模块，开发人员可以提示 Copilot 生成有意义的测试用例，即使测试覆盖率缺失或不一致也是如此。
通过使单元测试简化、加速、减少手动工作量，Copilot 可减少可能导致测试覆盖率差距的阻力，并帮助团队采用质量优先的思维模式。
用例
- 内联测试生成：开发人员可以要求 Copilot 为特定函数或模块生成测试，而无需切换上下文。
- 更好的边缘案例覆盖率：通过向 Copilot 提示边缘方案（例如 null 输入、空列表或无效状态），开发人员可以快速覆盖更多逻辑分支。
- 加速员工培训：通过使用 Copilot，新团队成员可以通过查看生成的测试用例来了解函数的预期行为方式。
- 有关 CI/CD 的帮助：Copilot 可以建议如何将测试集成到生成管道中，确保覆盖率改进可为质量门提供直接支持。
文化注意事项
在推出 GitHub Copilot 的同时，还应解决任何可能阻碍目标实现的社会或文化因素。
以下示例取自 ESSP 中的“反模式”部分。
- Teams 可能依赖于手动测试或不充分的自动化测试****。 可能原因是自动化资源约束或缺乏新式测试工具的经验。
- Teams 可能会等待太长时间进行发布，同时部署大量代码，使得 bug 和回归更难以检测****。 这可能是由于 CI/CD 管道成熟度不足、合规性要求严格或 PR 与部署之间评审周期较长。
3.在生产中
确定克服障碍的正确方法后，可缩放已确定的解决方案。 要成功推出新工具或新流程，请务必为推出的每个部分指定负责人、就目标进行透明沟通、提供有效的培训并衡量成果。
本部分为开发人员提供了示例场景、最佳做法和资源。 我们建议使用本部分来规划沟通和培训课程，以帮助员工以符合目标的方式使用 Copilot。****
内联生成测试
- 在 VS Code 中，选择要测试的函数并提示 Copilot：
Generate a unit test for this code. - Copilot 会以内联方式或在单独的测试文件中生成测试，具体取决于语言和结构。
- 评审、优化和接受建议。
覆盖边缘案例
-
编写测试后，询问 Copilot：
What are some edge cases I should test for this function?或者：
Write test cases for when the input is null or empty. -
Copilot 会建议其他测试用例来覆盖边界情况。
-
评审测试并将其合并到测试套件中。
了解新代码
- 选择旧函数并询问 Copilot：
Explain what this function does and generate a test to validate it. - Copilot 会解释函数的用途，并建议相应的测试用例。
- 查看测试用例以了解预期行为并快速生成上下文。
获取 CI/CD 的相关帮助
- 评审测试用例并将其提交到代码库。
- 询问 Copilot：
Where should I place this test if I want it to run in CI? - 根据代码库的结构，Copilot 将建议放置测试文件的位置以及如何更新管道配置。
适用于开发人员的最佳做法
开发人员应该：****
- 与 Copilot 聊天时，请使用描述性备注或提示。 例如：
Generate unit tests for a function that calculates discounts based on user type and purchase amount. - 使用 Copilot 检查逻辑覆盖率。 例如：
What branches or conditions does this function have that should be tested? - 探索不同的提示技术，并比较不同 AI 模型的结果。
开发人员不应该：****
- 在未评审逻辑的情况下接受生成的测试。 请确保测试反映实际要求并处理实际输入和输出。
- 跳过断言边缘行为。 如果仅测试“愉快路径”，则存在缺少回归的风险。
- 依赖于 Copilot 猜测未记录的业务规则。 请始终通过提示或备注提供上下文。
- 用 Copilot 替代人工代码评审。 Copilot 可加速该过程，但仍需应用工程判断。
面向开发人员的资源
- 使用 GitHub Copilot 编写测试
- 如何使用 GitHub Copilot 生成单元测试：提示和示例
- GitHub Copilot 在 Visual Studio 中随处可见（视频内容包含有关测试的部分）
- Copilot Chat 的提示设计
- 正在更改 Copilot Chat 的 AI 模型
推荐的功能
要监视的指标
若要评估新工具的试用情况，并确保全面推出后提供一致的改进，应监视结果并在需要时进行调整。 一般来说，建议考虑质量、速度和开发人员满意度这三大关键领域，并评估这些领域如何协同作用，共同推动业务成果的实现。****
下面是为评估 Copilot 对该特定目标的影响而建议查看的一些指标。
- 测试覆盖率：跟踪行和分支覆盖率在 Copilot 采用后的增加情况。 如果可能，请查看 CI 管道中的测试覆盖率报告。
- 部署后的 Bug 率：生产环境中报告的 bug 应减少。
- 开发人员置信度：使用调查或回顾来评估开发人员交付新代码的自信程度。
- 编写测试的时间：度量创建单元测试所需时间的减少情况。