AndroidStudio——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'

    }

}