本文是“ 持续集成,交付和部署”系列的一部分。
在上一篇文章中,我们探讨了单元测试 ,这是我们应该运行的第一组也是最快的一组测试。 现在是时候查看我们的单元测试是否提供足够的代码覆盖率了。
代码覆盖率
除非我们知道单元测试涵盖了相当大的代码覆盖范围,否则它们本身无法提供足够的信心。 例如,仅覆盖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 。 从左侧菜单中按“立即构建”按钮1 。 作业执行完成后,输入构建并单击“覆盖率报告”。 它将显示报告,包括指令,分支,复杂性,行,方法和类。
将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也是免费的,同时提供了更快的构建和一些不错的添加(例如存储工件)。
在下一篇文章中,我们将探讨连续交付和部署的最后阶段。 目标是持续部署(或至少交付)软件。 在这种情况下,连续意味着经常,快速且停机时间为零。 敬请关注。
- 提醒您:如果多次运行相同的构建而没有实际对代码进行任何更改,请确保擦除工作空间([JOB]>工作空间>清除当前工作空间)。 Gradle将检测到没有更改,并且什么也不做。 这是一件好事,因为这样可以节省很多时间,但是在测试Jenkins作业配置时可能会造成一些混乱。
翻译自: https://www.javacodegeeks.com/2014/11/continuous-delivery-code-coverage.html