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 {

     androidTest Compile '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/ androidTest s

它相似于 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'

    }

}