Android官方技術文檔翻譯——Gradle 外掛程式使用者指南（5），androidgradle

Android官方技術文檔翻譯——Gradle 外掛程式使用者指南（5），androidgradle

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

本文譯自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會進行測試。預設情況下是 debug Build 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'    }

}