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'
    }
}


posted @ 2017-08-06 12:57  zsychanpin  阅读(635)  评论(0)  编辑  收藏  举报