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

昨晚把第五章未译完的几句话攻克了。只是第六章没怎么译，明后天又是周末，假设周一前第六章翻译完的话，周一再发第六章。

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

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

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

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

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

翻译工作耗时费神。假设你认为本文翻译得还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'

}

}