在过去的 10 个月中，edX 的开发人员一直在努力提高自动化测试的覆盖率。 我们的 2,491 个 Python 单元测试目前覆盖了 edx-platform 存储库中 87% 的行。 这些测试，连同我们的 Selenium 验收测试和 JavaScript 单元测试，在每个拉取请求上运行，使我们能够快速验证提议的代码更改。
我们如何在短短 50 个月内将测试覆盖率从不到 87% 提高到 10%？ 部分答案是一个名为 差异覆盖.
在典型的工作流程中，在大型项目中工作的开发人员可能会提出一个更改几十行代码的拉取请求。 在更改之前，测试覆盖率可能已经达到 72%； 之后，它仍然可能是 72%。 项目的规模使得很难看到单个拉取请求的效果。 Diff-cover 让您专注于单个拉取请求的质量指标，而不是整个项目。
Diff-cover 测量 git diff 中的代码行。 对于建议的代码更改，它将显示哪些更改的行缺少覆盖。 这是一个简单的想法，但它具有强大的含义：
- 对于开发人员来说，diff-cover 提供了一个清晰且可实现的指标：如果您触及一行代码，它应该被覆盖。
- 对于代码审阅者，diff-cover 可以更轻松地验证开发人员是否正在为所有代码更改编写测试。
通过关注差异覆盖率，开发人员可以采取小而明显的步骤来提高全球覆盖率。 特定的提交可能会增加 全球化 覆盖率只有百分之几，但仍有 95% 差异 覆盖范围。 随着开发人员为他们的代码更改编写测试，缓慢但肯定地，全球覆盖率也开始增加。 结果，我们能够更快地捕获某些类型的错误。
更重要的是，其他开发人员开始为 diff-cover 自己做出贡献并接管该工具。 例如，Cale 推广了该工具以支持额外的“质量”检查，而 Sarina 将其扩展为在 diff 中报告 pep8 和 Pylint 违规。 许多其他开发人员在 diff-cover 的初始 beta 测试期间提供了反馈和建议。 该工具成为重新检查我们的代码审查和测试标准的起点，这导致我们的测试文化发生了真正的变化。
当然，覆盖测量仍然有一些重要的限制。 特别是，高差异覆盖率确实 不会 保证代码无错误：在紧密耦合的系统中，对一个组件的更改可能会对系统的其他部分产生深远而意想不到的后果——即使更改的代码被 100% 覆盖。 在这种情况下，集成测试可以捕获单元测试可能遗漏的错误。
如果您认为 diff-cover 可能对您有用，请查看该项目——它是开源的，并且 在GitHub上可用. 该代码旨在可扩展到其他版本控制系统和质量检查器，因此请随时添加功能并提出拉取请求！
Will Daly 是 edX 的测试工程师。 当他不提倡测试驱动开发或优化 Jenkins 集群时，他喜欢沿着河流奔跑并尽量减少他公寓里的东西。
