编写移动应用程序很难，编写好的和可的应用程序就更加困难了。在开发过程中，我们需要对代码库的每次修改不会降低代码质量和功能的可用性。
在现代的移动应用开发中，很难想象在没有编写测试特别是单元测试的情况下，你可以做出一个可靠的和可的应用。但我们经常遇到一个问题：要编写多少的测试用例才能足够这段代码能够被测试正确的覆盖。嗯，这没有明确的答案，但今天我想介绍一个名为 JaCoCo 这款很棒的工具，它有助于有价值的代码被单元测试覆盖到。
JaCoCo 全称是 Java Code Coverage tool，它已经在 Java 开发者中使用数十年了，但如果配置得当的话， Android 开发者也可以利用它获得益处。社区已经有很多文章介绍 Android 工程中如何配置 JaCoCo 从而生成测试覆盖报告，因此我就不再深入介绍这个主题。相反我将展示如何为 JaCoCo 测试覆盖配置自动校验功能，从而方便将其引入你的构建或者 CI 管道（pipeline）中。
在这个示例工程中我实现了一个很基础的 MVP 模式。这意味着我们将 Activities 视为被动的 View，所有有用的 UI 逻辑放在 Presenters 中。让我们仔细看下 LoginPresenter，它有一个键盘输入处理，登录和密码的校验，以及授权逻辑本身。如果一切校验没有问题的话，那么登录成功后我们就进入 MainActivity。在 LoginPresenterTest 中有一些单元测试。MVP 模式的规则是保持 View 层拥有尽可能少的代码，同时，将业务逻辑保留在 Presenters 中，从而使得这部分逻辑代码能够很容易被单元测试覆盖到。我们将按这种方式来配置 JaCoCo。我们将忽略 View 层和一些 Android 相关的类，为除此以外其他的类的代码生成测试覆盖报告。
如果我们的工程结构是按照特性来组织的，那么通过配置com/androidjacoco/sample/**/view/**.*这个过滤器规则就可以忽略现在以及将来可能增加的所有的 View 类。
Missed Instructions：提供关于被执行（注：指被单元测试覆盖到）或者没有被执行的代码量信息，单位是一条 Java 字节码指令。
Missed Branches：用于计算一个方法中此类分支的总个数，并确定被执行或者没有被执行的分支数量。
让我们看一下 LoginPresenter 类，并确保其中确实有很多没有被执行到的指令和分支。
现在如果我们不想让测试覆盖率如此低的代码进入到生产中，我们能做些什么呢？JacocoCoverageVerification 这个 task 能够帮我们解决这个问题！
这个 task 依赖于前面的 customJacocoTestReport task，如果执行它，将会首先生成测试覆盖报告然后接着对其进行分析。这个 task 的配置中包含如何找到源代码类所在的径，以及 violationRules 配置块。violationRules 配置块本身又包含了一些规则块，只要你愿意，你可以添加尽可能多的这种规则块。在这个例子中，我配置了三个规则块：
如果代码分支（if，switches 等）有多达 80% 以上没有被单元测试覆盖到，那么构建将会失败：
在这个规则中我声明了在 presenter 包中的每个类都必须至少有一个单元测试。请注意所有匿名类都会被当作一个个的类来对待。
想要了解更多关于规则的语法，可查看：。（注：关于在 gradle 中配置 JaCoCo，可以参见这里）
在这个示例工程仓库的 VerificationPassed 分支，你可以看到覆盖率满足规则的代码。通过这种方式，你可以配置构建脚本，并将测试覆盖率验证添加到构建过程中。
JaCoCo 是一个功能强大的工具，可以帮助你增加代码仓库的测试覆盖率。当然，如何定义规则和代码覆盖率取决于你的和具体项目的需求，但这是一个很好的代码仓库的健康指标，值得尝试将其引入你的构建管道中。在我们的项目中，测试覆盖率从开始的 0.4 慢慢增加到 0.6，并且还在继续增长。
推荐：
网友评论 ()条 查看