昨晚把第五章未譯完的幾句話解決了，不過第六章沒怎麼譯，明後天又是週末，如果週一前第六章翻譯完的話，週一再發第六章。

本文譯自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

翻譯工作耗時費神，如果你覺得本文翻譯得還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'     }

}