Android官方技术文档翻译——Gradle 插件用户指南（六）_Android

Android官方技术文档翻译——Gradle 插件用户指南（6）

没想到翻译这篇《Gradle 插件用户指南》拖了差不多一个月，还跨年了。不过还好，在2号时终于一口气把剩下的给翻译完了（其实那天剩下的也就不到一章）。

今天先发一下第六章，明天再发第七章。

本文译自Android官方技术文档《Gradle Plugin User Guide》,原文地址：http://tools.android.com/tech-docs/new-build-system/user-guide。

翻译不易，转载请注明CSDN博客上的出处：

http://blog.csdn.net/maosidiaoxian/article/details/42386877

前三章见《Android官方技术文档翻译——Gradle 插件用户指南（1-3）》。

第四章见《Android官方技术文档翻译——Gradle 插件用户指南（4）》。

第五章见《Android官方技术文档翻译——Gradle 插件用户指南（5）》。

翻译工作耗时费神，如果你觉得本文翻译得还OK，请点击文末的“顶”，我在精神上会倍受鼓励的，谢谢。翻译如有错讹，敬请指正。

测试

构建一个测试应用程序已经集成到应用程序项目中了。所以已经没有必要再去创建一个单独的测试项目。

基础知识和配置

正如前面所提及，在main sourceSet旁边的是androidTest sourceSet，默认情况下，它位于src /androidTest/
从这里的 sourceSet 构建出来的是一个测试的apk，它可以部署到设备上，使用 Android 的测试框架去测试应用程序。它可以包含单元测试、 instrumentation 测试和后来的 uiautomator 测试。这个
SourceSet 不应该包含 AndroidManifest.xml ，因为它是会自动生成的。

下面是可以用来配置测试应用程序的几个值：

testPackageName
testInstrumentationRunner
testHandleProfiling
testFunctionalTest

正如前面所看到的，它们在defaultConfig对象中配置：

android {
defaultConfig {
testPackageName "com.test.foo"
testInstrumentationRunner "android.test.InstrumentationTestRunner"
testHandleProfiling true
testFunctionalTest true
}
}

在测试程序里的manifest里的instrumentation节点中，targetPackage属性的值会自动设为被测试的应用程序的包名称，即使它通过defaultConfig或Build Type对象自定义过。这是manifest 自动生成的原因之一。

此外，sourceSet可以配置自己的依赖。
默认情况下，应用程序和它自己的依赖都会被添加到测试应用程序的classpath中，但是也可以通过以下来扩展

dependencies {
androidTestCompile 'com.google.guava:guava:11.0.2'
}

这个测试程序是由assembleTest任务构建的。它不是main里的assemble任务的依赖项，当设置测试运行时它不会被自动调用。

目前只有一种Build Type会进行测试。默认情况下是debugBuild Type，但它可以被重新配置：

android {
...
testBuildType "staging"
}

运行测试

正如前面提到的，通过锚任务 connectedCheck运行的检查，需要一个已连接的设备。

它依赖于任务androidTest，因此将运行 androidTest。该任务执行以下操作：

确保应用程序和测试应用程序都被构建（依赖于 assembleDebug 和 assembleTest)
安装这两个应用程序
运行测试
卸载这两个应用程序。

如果连接了多个设备，所有的测试都会并行运行在所有连接的设备上。如果任何一个设备的其中一项测试失败，那么整个构建都将失败。

所有测试结果都会保存为 XML 文件，路径为

build/androidTest-results

（这类似于 jUnit 定期运行的结果保存在 build/text-result 下面）

它可以通过以下方式来配置
配置

android {
...

testOptions {
resultsDir = "$project.buildDir/foo/results"
}
}

Android.testOptions.resultsDir的值将通过Project.file(String) 获得

测试 Android Libraries

测试 Android Library项目与测试应用程序项目的方式完全一样。

唯一的区别是整个库（和它的依赖项）会自动作为Library依赖添加到测试应用程序中。结果就是测试 APK 不只包含其自己的代码，还包括测试库以及测试库的所有依赖项。
这个Library的manifest 会合并到测试应用程序的manifest中（如引用此Library的任何项目）。

AndroidTest任务改为仅安装（以及卸载）测试 APK （因为没有其他的 APK 要安装）

其他的都是相同的。

测试报告

当运行单元测试时，Gradle 会输出 HTML 报告，以方便查看结果。
Android 插件在此基础上扩展了 HTML 报告，它聚合了所有连接的设备的测试结果。

单个项目的报告

这个测试报告的项目会在运行测试时自动生成。它的默认位置是

build/reports/androidTests

它类似于 jUnit 报告的位置build/reports/tests，或其他通常位于build/reports/<plugin>/的报告。

这个位置可以通过以下方式自定义

android {
...

testOptions {
reportDir = "$project.buildDir/foo/report"
}
}

该报告将聚合在不同的设备运行的测试。

多项目报告

在一个设置了一个或多个application和 library 项目的多项目中，当同时运行所有的测试，为所有测试生成单个报告可能是非常有用的。

要做到这一点，需要使用同一个文件中的另一个插件。这个插件可以如下配置：

buildscript {
repositories {
mavenCentral()
}

dependencies {
classpath 'com.android.tools.build:gradle:0.5.6'
}
}

apply plugin: 'android-reporting'

这个插件应该在根项目中配置使用，即在 settings.gradle同级目录的build.gradle中。

然后在根文件夹中，下面的命令就可以运行所有的测试并聚合测试报告：

gradle deviceCheck mergeAndroidReports --continue

注： --continue选项确保所有子项目的测试都会被运行，即使其中的一个子项目的测试失败了。如果不加上这个选项，第一个失败的测试将会中断所有测试的运行，这可能导致有些项目还没有执行它们的测试。

Lint 支持

从 0.7.0 版本起，您可以为一个指定的variant或所有的variants 运行lint，在这种情况下，它会生成一个报告，描述每一个给定的问题都存在于哪些指定的variants 。

您可以通过添加以下的一个 lintOptions 节点对lint进行配置。通常，您只需要指定其中的几个；以下列出了所有可用的选项。

android {

lintOptions {

  // 设置为 true时lint将不报告分析的进度
quiet true
  // 如果为 true，则当lint发现错误时停止 gradle构建
abortOnError false
  // 如果为 true，则只报告错误
ignoreWarnings true
  // 如果为 true，则当有错误时会显示文件的全路径或绝对路径 (默认情况下为true)
//absolutePaths true
  // 如果为 true，则检查所有的问题，包括默认不检查问题
checkAllWarnings true
  // 如果为 true，则将所有警告视为错误
warningsAsErrors true
  // 不检查给定的问题id
disable 'TypographyFractions','TypographyQuotes'
  // 检查给定的问题 id
enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'
  // * 仅 * 检查给定的问题 id
check 'NewApi', 'InlinedApi'
  // 如果为true，则在错误报告的输出中不包括源代码行
noLines true
  // 如果为 true，则对一个错误的问题显示它所在的所有地方，而不会截短列表，等等。
showAll true
  // 重置 lint 配置（使用默认的严重性等设置）。
lintConfig file("default-lint.xml")
  // 如果为 true，生成一个问题的纯文本报告（默认为false）
textReport true
  // 配置写入输出结果的位置；它可以是一个文件或 “stdout”（标准输出）
textOutput 'stdout'
  // 如果为真，会生成一个XML报告，以给Jenkins之类的使用
xmlReport false
  // 用于写入报告的文件（如果不指定，默认为lint-results.xml）
xmlOutput file("lint-report.xml")
  // 如果为真，会生成一个HTML报告（包括问题的解释，存在此问题的源码，等等）
htmlReport true
  // 写入报告的路径，它是可选的（默认为构建目录下的 lint-results.html ）
htmlOutput file("lint-report.html")

// 设置为 true，将使所有release 构建都以issus的严重性级别为fatal（severity=false）的设置来运行lint
// 并且，如果发现了致命（fatal）的问题，将会中止构建（由上面提到的 abortOnError 控制）
checkReleaseBuilds true
// 设置给定问题的严重级别（severity）为fatal （这意味着他们将会
// 在release构建的期间检查（即使 lint 要检查的问题没有包含在代码中)
fatal 'NewApi', 'InlineApi'
// 设置给定问题的严重级别为error
error 'Wakelock', 'TextViewEdits'
// 设置给定问题的严重级别为warning
warning 'ResourceAsColor'
// 设置给定问题的严重级别（severity）为ignore （和不检查这个问题一样）
ignore 'TypographyQuotes'
}

}