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

浏览数：29 / 时间：2015年06月11日

昨晚把第五章未译完的几句话解决了，不过第六章没怎么译，明后天又是周末，如果周一前第六章翻译完的话，周一再发第六章。

本文译自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‘
    }
}


郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。

标签： Android iOS 移动互联 终端开发

相关文章

随机文章

您可能还喜欢

您可能还喜欢