连续交付：代码覆盖率

本文是“ 持续集成，交付和部署”系列的一部分。

在上一篇文章中，我们探讨了单元测试 ，这是我们应该运行的第一组也是最快的一组测试。 现在是时候查看我们的单元测试是否提供足够的代码覆盖率了。

代码覆盖率

除非我们知道单元测试涵盖了相当大的代码覆盖范围，否则它们本身无法提供足够的信心。 例如，仅覆盖15％的代码才能使所有测试成功，则无法提供足够的信任。

成熟的团队可能不需要衡量代码覆盖率。 他们可能会从经验中知道，他们的单元测试所覆盖的代码与他们正在研究的项目一样多。 这样的团队往往在测试驱动开发（TDD）方面拥有多年的实践经验。 但是，对于我们大多数人而言，衡量覆盖率的工具确实是对我们的工具带非常有用的补充。

什么是代码覆盖率？

代码覆盖率是我们用来检查测试了多少源代码的一种度量。 代码覆盖率越高，已测试代码的百分比就越大。

要了解的重要一点是，代码覆盖率与代码质量没有直接关系。 高代码覆盖率不能保证这些测试的高质量。 例如，即使100％的代码覆盖率，也不能保证某些功能是否正确开发或根本没有开发。

尽管代码覆盖率可用于任何类型的测试，但将其与单元测试联系在一起是最常见和有用的。 集成和功能测试也可以测量，但是对结果的期望必须有所不同。

有关更多信息，请查阅《代码和测试范围》 。

让我们看看如何在CI / CD工具中实现代码覆盖率。

对于那些没有详细阅读先前文章的人或那些未能复制所有练习的人，请安装Vagrant并从存储库TechnologyConversationsCD中克隆代码。 要使用执行静态分析的Jenkins和myFirstJob作业创建虚拟机，请转到克隆的存储库中的目录server / jenkinsWithTests并执行以下命令：

vagrant up

如果这不是您第一次启动该无用虚拟机（“ vagrant up”配置为仅初次运行Docker容器），或者由于某种原因而没有运行Docker容器，则可以使用以下快捷方式脚本运行它。

/opt/start_docker_with_jenkins.sh

我们可以通过执行以下命令来检查正在运行的容器：

docker ps

完成后，具有Jenkins和myFirstJob作业的虚拟机将启动并运行。 通过在浏览器中打开http：// localhost：8080可以看到结果。

我们将继续使用Gradle作为构建工具。 在上一篇文章中，我们执行Gradle任务检查以运行静态分析（CheckStyle，FindBugs和PMD）和测试。 现在，我们将使用JaCoCo添加代码覆盖率。

要添加JaCoCo代码覆盖率，只需将插件添加到build.gradle文件即可。

apply plugin: 'jacoco'

好消息是，如果使用JaCoCo插件，它将自身添加到Gradle任务检查和测试中 。 由于我们已经有运行Gradle 检查任务的Jenkins作业，因此无需告诉JaCoCo收集测试统计信息。

但是，JaCoCo需要执行两次。 一种是从我们的测试中收集数据（已经在Gradle 检查任务中介绍过）。 第二个是从收集的数据生成HTML报告。 为了做到这一点，我们应该通过将jacocoTestReport添加到Gradle任务列表中来更改Jenkins作业myFirstJob中的Gradle调用。 现在看起来应该像这样：

clean check jacocoTestReport

要发布JaCoCo覆盖率报告，我们需要安装JaCoCo插件（Jenkins>管理Jenkins>管理插件>可用）。 安装插件后，我们可以添加名为“记录JaCoCo覆盖率报告”的构建后操作。 在“执行文件路径”中输入“ / .exec”（JaCoCo将coverage数据保存到.exec文件中）。 应该将“类目录的路径”设置为“ / classes”，以便包括所有以前使用Gradle编译的目录。 最后，我们应该将“源目录路径”设置为“ / src / main / java”。 其余参数与承保范围健康相关，并取决于团队的偏好。 我倾向于认为90％的代码覆盖率是可以接受的。 超过95％通常适得其反。

而已。 我们已经准备好构建包含JaCoCo代码覆盖范围的myFirstJob 。 从左侧菜单中按“立即构建”按钮¹ 。 作业执行完成后，输入构建并单击“覆盖率报告”。 它将显示报告，包括指令，分支，复杂性，行，方法和类。

将JaCoCo集成到Jenkins中非常容易。 困难的部分是要达到通过测试的代码覆盖率相当高的地步。 掌握TDD以及功能和集成测试（我的首选是BDD ）是关键。

Travis与JaCoCo的比赛表现不佳。 当然，以与Jenkins相同的方式在Gradle中运行它很容易。 但是，没有简单的方法来获取和发布结果。 在测试结果的情况下，无法发布不是问题，因为我们仅关注是否存在某些失败的测试，并且可以从日志中轻松查看哪个失败。 由于应该尽快修复失败的测试，因此没有报告的真正原因。 代码覆盖范围不同。 由于在大多数情况下，通过测试获得的代码覆盖率不是100％，因此查看和查看结果的能力非常重要。

与Travis一样， CircleCI不需要执行任何特殊操作即可运行代码覆盖率，因为它是Gradle任务检查的一部分 （假设我们添加了JaCoCo Gradle插件）。

在上一篇文章中我们已经看到，Circle在CI方面与Travis非常相似。 主要区别在于稳定性和速度（比Travis快几倍）。 通过代码覆盖，我们可以探索另一个差异。 Circle可以选择存储构建工件。 有了它们，我们可以实现与詹金斯相似的效果。 我们将允许用户查看Gradle代码覆盖率以及其他类型的报告。 我们需要做的就是通过添加jacocoTestReport并确保将所有报告添加到CircleCI工件来修改circle.yml文件。

[circle.yml]

test:
  override:
    - gradle check jacocoTestReport
  post:
    - cp -R build/reports/* $CIRCLE_ARTIFACTS

完整的源代码可以在circle.yml中找到。

将更改提交到存储库后，CircleCI将存储我们的所有报告，并通过每个版本中可用的“工件”选项使其可用。 通过打开jacoco / test / html / index.html，我们可以看到JaCoCo为我们生成的漂亮报告。

摘要

设置代码覆盖率并在Jenkins和CircleCI中发布结果都相当容易。 我们唯一要做的就是告诉他们运行Gradle任务jacocoTestReport以及在哪里找到结果。 另一方面，特拉维斯（Travis）没有发布报告的选项。 没有它们，代码覆盖几乎是无用的。

Jenkins的插件系统继续发光。 Circle的“构建工件”令人惊喜，并且是其速度的另一个便捷之选。 我使用它的次数越多，与Travis相比，我看到的优势就越多。 特拉维斯的价格无与伦比（公共存储库免费）。 但是，自从最近CircleCI也是免费的，同时提供了更快的构建和一些不错的添加（例如存储工件）。

在下一篇文章中，我们将探讨连续交付和部署的最后阶段。 目标是持续部署（或至少交付）软件。 在这种情况下，连续意味着经常，快速且停机时间为零。 敬请关注。

1. 提醒您：如果多次运行相同的构建而没有实际对代码进行任何更改，请确保擦除工作空间（[JOB]>工作空间>清除当前工作空间）。 Gradle将检测到没有更改，并且什么也不做。 这是一件好事，因为这样可以节省很多时间，但是在测试Jenkins作业配置时可能会造成一些混乱。

翻译自: https://www.javacodegeeks.com/2014/11/continuous-delivery-code-coverage.html