通过GitHub Copilot提高公司的测试覆盖率

了解功能、启用开发人员并衡量Copilot的影响。

谁可以使用此功能？

GitHub Copilot业务 or GitHub Copilot Enterprise

在本文中

本指南的灵感来自 GitHub 的工程系统成功 playbook (ESSP)，其中推荐了推动工程系统改进的策略和指标。

如果你要启动 Copilot 的推出，我们建议定义目标、相应地规划推出，并向员工明确传达目标。 请参阅“使用 GitHub Copilot 实现公司工程目标”。

1.确定阻碍成功的因素

ESSP 建议的第一步是充分了解阻碍公司取得进步的障碍。 通过了解当前的基线、所需的未来状态以及阻碍进步的障碍，可确保更改具有针对性且有效。

由于单元测试覆盖率较低，许多软件团队在维护高质量代码方面面临持续挑战。 在快节奏的开发环境中，编写测试通常被视为耗时或不必要，尤其是在团队面临快速交付功能的压力时。

因此，关键 bug 可能在开发生命周期的后期才被发现，通常是在过渡或生产环境中。

这会导致一系列负面结果：

  • 更高的 bug 率以及客户反馈的问题增加****
  • 部署后修复 bug 的成本增加****
  • 降低开发人员对其代码稳定性的信心****
  • 反应式调试和修补导致发布周期变慢****

在旧系统中，由于复杂的依赖项或记录不佳的代码，测试覆盖率问题可能更难解决。 开发人员可能不熟悉较旧的代码库或一般测试框架，这进一步加剧了问题。

提高测试覆盖率是公认的最佳做法，但需要时间和专业知识，而许多团队无法满足这些要求。

2.评估你的选项

下一步是评估并商定解决方案，以解决在第一步中确定的障碍。 在本指南中，我们将重点关注 GitHub Copilot 对已确定目标的影响。 新工具的成功推出还需要对文化和流程进行更改。

使用试点组运行新工具和流程的试用，以收集反馈并衡量成功。 有关在试验期间要使用的训练资源和指标，请参阅 3. 实施更改 和 需要监视的指标 部分。

          <a href="https://github.com/github-copilot/purchase?ref_product=copilot&ref_type=trial&ref_style=button&ref_plan=enterprise" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline">
          <span>注册 Copilot</span><svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-link-external" aria-label="link external icon" role="img"><path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path></svg></a>

如何 Copilot 能提供帮助

          GitHub Copilot 可以显著加速和简化编写单元测试的过程。 通过了解周围的代码和上下文， Copilot 可以建议与所测试代码的结构和逻辑匹配的测试函数。

          Copilot的功能在多个场景中非常有用：
  • 当开发人员编写新函数时， Copilot 可以自动内联建议相应的测试用例。
  • 重构旧代码时， Copilot 可以帮助生成测试基架以防止回归。
  • 对于未经测试的模块，开发人员可以提示 Copilot 生成有意义的测试用例，即使测试覆盖率缺失或不一致。

通过简化单元测试、更快和更少的手动测试， Copilot 可减少可能导致测试覆盖率差距的摩擦，并帮助团队采用质量优先的思维模式。

用例

  •         **内联测试生成**：开发人员可以要求 Copilot 为特定函数或模块生成测试，而无需切换上下文。

  •         **更好的边缘案例覆盖率**：通过提示 Copilot 边缘方案（例如 null 输入、空列表或无效状态），开发人员可以快速覆盖更多逻辑分支。

  •         **加速载入**：新团队成员可以通过 Copilot 查看生成的测试用例来了解函数的行为方式。

  •         **有关 CI/CD 的帮助**： Copilot 可以建议如何将测试集成到生成管道中，确保覆盖率改进直接支持质量入口。

文化注意事项

除了推出 GitHub Copilot 外，还要解决可能阻碍你实现目标的任何社会或文化因素。

以下示例取自 ESSP 中的“反模式”部分。

  • Teams 可能依赖手动测试或不充分的自动化测试****。 可能原因是自动化资源约束或缺乏新式测试工具的经验。
  • 团队可能会等待太长时间才进行软件发布，并同时部署一个大批代码，这使得检测缺陷和回归变得更加困难。 这可能是由于 CI/CD 管道成熟度不足、合规性要求严格或 PR 与部署之间评审周期较长。

3. 实施更改

确定克服障碍的正确方法后，请实施并扩大你确定的解决方案。 若要成功推出新工具或流程，请将所有权分配给推出的每个部分，以透明方式传达目标，提供有效的培训，并衡量结果。

本部分为开发人员提供了示例场景、最佳做法和资源。 使用本部分来规划通信和培训课程，帮助员工以符合你的目标的方式使用 Copilot。

  •         [内联生成测试](#generate-tests-inline)

  •         [覆盖边界情况](#cover-edge-cases)

  •         [了解新代码](#understand-new-code)

  •         [获取 CI/CD 的相关帮助](#get-assistance-with-cicd)

  •         [面向开发人员的最佳做法](#best-practices-for-developers)

  •         [面向开发人员的资源](#resources-for-developers)

  •         [推荐的功能](#recommended-features)

内联生成测试

  1. 在 VS Code 中，选择要测试和提示 Copilot的函数： Generate a unit test for this code.
  2.        Copilot 根据语言和结构，可在内联或单独的测试文件中生成测试。
  3. 评审、优化和接受建议。

覆盖边缘案例

  1. 在编写完测试后，询问 Copilot： What are some edge cases I should test for this function?

    或者：Write test cases for when the input is null or empty.

  2.        Copilot 建议其他测试用例以涵盖边界条件。

  3. 审核测试并将其整合到测试套件中。

了解新代码

  1. 选择旧函数并询问 Copilot： Explain what this function does and generate a test to validate it.
  2.        Copilot 解释函数的目的，并建议相应的测试用例。
  3. 查看测试用例以了解预期行为并快速生成上下文。

获取 CI/CD 的相关帮助

  1. 评审测试用例并将其提交到代码库。
  2. 问 Copilot： Where should I place this test if I want it to run in CI?
  3. 根据代码库的结构， 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 加速该过程，但仍需要应用工程判断。

面向开发人员的资源

  •         [AUTOTITLE](/copilot/using-github-copilot/guides-on-using-github-copilot/writing-tests-with-github-copilot)

  •         [如何使用GitHub Copilot生成单元测试：提示和示例](https://github.blog/ai-and-ml/github-copilot/how-to-generate-unit-tests-with-github-copilot-tips-and-examples/)
  • 在 Visual Studio 中随处可见（包含测试部分的视频内容）
  •         [AUTOTITLE](/copilot/using-github-copilot/copilot-chat/prompt-engineering-for-copilot-chat)

  •         [AUTOTITLE](/copilot/using-github-copilot/ai-models/changing-the-ai-model-for-copilot-chat)
  • GitHub 中的Copilot 对话助手
  •         [
        Copilot 内联建议](/copilot/using-github-copilot/getting-code-suggestions-in-your-ide-with-github-copilot)

  •         [
        Copilot 对话助手 在 IDE 中](/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-your-ide)
  • Copilot云代理

要监视的指标

若要评估新工具的试用，并确保完整的推出提供一致的改进，请监视结果并在需要时进行调整。 我们建议考虑 质量、速度和开发人员幸福的关键区域，以及这些区域如何结合在一起，为业务成果做出贡献。

下面是一些指标，用于评估 Copilot 对此特定目标的影响。

  •         **测试覆盖率**：跟踪采用后的 Copilot 行和分支覆盖范围的增加。 如果可能，请查看 CI 管道中的测试覆盖率报告。

  •         **部署后的 Bug 率**：生产环境中报告的 bug 应减少。

  •         **开发人员置信度**：使用调查或回顾来评估开发人员交付新代码的自信程度。

  •         **编写测试的时间**：度量创建单元测试所需时间的减少情况。