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'

    }

}