测试策略

**默认情况下，所有进入 mozilla-central 的代码都包含自动化测试。** 每个提交都包含测试，涵盖每个主要的功能和预期的输入条件。

根据审查者的判断，在提交代码之前，必须在 Phabricator 中应用以下项目标签之一

• testing-approved 如果代码具有足够的自动化测试覆盖率。

• 如果代码没有足够的自动化测试覆盖率，则使用 testing-exception-* 中的一个。在与项目中的许多团队沟通后，我们确定了最常见的例外情况，如下所述。

例外情况

• testing-exception-unchanged：不会改变最终用户行为的提交。例如

  • 重构、机械更改以及删除死代码，只要它们没有显著更改或删除任何现有测试。作者在重构之前，应该考虑检查并添加缺少的测试覆盖率（在单独的提交中）。

  • 不会发布给用户的代码（例如：文档、构建脚本和清单文件、mach 命令）。当出现回归可能会导致开发人员出现故障或困惑时，应努力对其进行测试，但这由审查者自行决定。

• testing-exception-ui：更改 UI 样式、图像或本地化字符串的提交。虽然我们有端到端的自动化测试来确保前端没有完全崩溃，并且可以基于屏幕截图跟踪随时间的变化，但我们目前仅依靠手动测试和错误报告来发现样式回归。

• testing-exception-elsewhere：测试存在但位于其他地方的提交。这**需要审查者提供评论**，说明测试位于何处。例如

  • 在 Stack 中的另一个提交中。

  • 在后续的 Bug 中。

  • 在第三方代码的外部存储库中。

  • 在遵循安全 Bug 批准流程时，测试通常会稍后提交，但应在与提交同时编写和审查。

• testing-exception-other：上面定义的任何例外情况都不适用的提交，但仍应提交。在使用此标签之前，应由审查者仔细审查 - 考虑是否确实需要例外情况，或者是否可以在使用之前合理地添加测试。这**需要审查者提供评论**，解释为什么在没有测试的情况下提交代码是合适的。一些已识别的示例包括

  • 与外部硬件或软件交互，而我们的代码缺少模拟交互的抽象。

  • 无法重现报告的问题，因此提交了一些内容以在 Nightly 中测试修复。

Phabricator WebExtension

在 Phabricator 上接受补丁时，phab-test-policy 扩展程序将显示可用测试标签列表，以便您可以更快地添加标签。