標籤:
原文地址:http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing
5、Testing(測試)
構建一個測試程式已經被整合到應用項目中,沒有必要再專門建立一個測試項目。
5.1 Basics and Configuration(基本知識和配置)
正如前面所提到的,緊鄰main sourceSet的就是androidTest sourceSet,預設路徑在src/androidTest/下。
在這個測試sourceSet中會構建一個使用Android測試架構,而且能夠部署到裝置上的測試apk來測試應用程式。這裡麵包括單元測試,整合測試。和興許UI自己主動化測試。
這個測試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屬性值會自己主動使用測試應用的package名稱設定。即使這個名稱是通過defaultConfig或者Build Type對象自己定義的。這也是manifest檔案須要自己主動產生的一個原因。
另外。這個測試sourceSet也能夠擁有自己的依賴。
預設情況下,應用程式和他的依賴會自己主動加入的測試應用的classpath中。可是也能夠通過下面來擴充:
dependencies { androidTestCompile 'com.google.guava:guava:11.0.2' }
測試應用通過assembleTest task來構建。
assembleTest不依賴於main中的assemble task。須要手動設定執行,不能自己主動執行。
眼下僅僅有一個Build Type被測試。預設情況下是debug Build Type,可是這也能夠通過下面自己定義配置:
android { ... testBuildType "staging" }
5.2 Running tests(執行測試)
正如前面提到的。標誌性task connectedCheck要求一個串連的裝置來啟動。
這個過程依賴於androidTest task,因此將會執行androidTest。這個task將會執行以下內容:
* 確認應用和測試應用都被構建(依賴於assembleDebug和assembleTest)。
* 安裝這兩個應用。
* 執行這些測試。
* 卸載這兩個應用。
假設有多於一個串連裝置。那麼全部測試都會同一時候執行在全部串連裝置上。假設當中一個測試失敗,無論是哪一個裝置算失敗。
全部測試結果都被儲存為XML文檔。路徑為:
build/androidTest-results
(這類似於JUnit的執行結果儲存在build/test-results)
相同,這也能夠自己定義配置:
android { ... testOptions { resultsDir = "$project.buildDir/foo/results" } }
這裡的android.testOptions.resultsDir將由Project.file(String)獲得。
5.3 Testing Android Libraries(測試Android庫)
測試Android庫項目的方法與應用項目的方法類似。
唯一的不同在於整個庫(包括它的依賴)都是自己主動作為依賴庫被加入到測試應用中。結果就是測試APK不單僅僅包括它的代碼,還包括了庫項目自己和庫的全部依賴。
庫的manifest被組合到測試應用的manifest中(作為一些項目引用這個庫的殼)。
androidTest task的變改僅僅是安裝(或者卸載)測試APK(由於沒有其他APK被安裝)。
其他的部分都是類似的。
5.4 Test reports(測試報告)
當執行單元測試的時候,Gradle會輸出一份HTML格式的報告以方便查看結果。
Android plugin也是基於此,而且擴充了HTML報告檔案,它將全部串連裝置的報告都合并到一個檔案中面。
5.4.1 Single projects(獨立項目)
一個項目將會自己主動產生測試執行。預設位置為:build/reports/androidTests
這很類似於JUnit的報告所在位置build/reports/tests,其他的報告通常位於build/reports/<plugin>/。
這個路徑也能夠通過下面方式自己定義:
android { ... testOptions { reportDir = "$project.buildDir/foo/report" } }
報告將會合并執行在不同裝置上的測試結果。
5.4.2 Multi-projects reports(多項目報告)
在一個配置了多個應用或者多個庫項目的多項目裡。當同一時候執行全部測試的時候,產生一個報告檔案記錄全部的測試可能是很實用的。
為了實現這個目的,須要使用同一個依賴檔案(譯註:指的是使用android gradle外掛程式的依賴檔案)中的還有一個外掛程式。能夠通過下面方式加入:
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選項將同意所有測試。即使子項目中的不論什麼一個執行失敗都不會停止。
假設沒有這個選項,第一個失敗測試將會終止所有測試的執行。這可能導致一些項目沒有執行過它們的測試。
5.5 Lint support(Lint支援,譯者註:Lint是一個能夠檢查Android項目中存在的問題的工具)
從0.7.0版本號碼開始。你能夠為項目中一個特定的Variant(變種)版本號碼執行lint。也能夠為全部Variant版本號碼都執行lint。
它將會產生一個報告描寫敘述哪一個Variant版本號碼中存在著問題。
你能夠通過下面lint選項配置lint。
通常情況下你僅僅須要配置當中一部分。下面列出了全部可使用的選項:
android { lintOptions { // set to true to turn off analysis progress reporting by lint quiet true // if true, stop the gradle build if errors are found abortOnError false // if true, only report errors ignoreWarnings true // if true, emit full/absolute paths to files with errors (true by default) //absolutePaths true // if true, check all issues, including those that are off by default checkAllWarnings true // if true, treat all warnings as errors warningsAsErrors true // turn off checking the given issue id's disable 'TypographyFractions','TypographyQuotes' // turn on the given issue id's enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // check *only* the given issue id's check 'NewApi', 'InlinedApi' // if true, don't include source code lines in the error output noLines true // if true, show all locations for an error, do not truncate lists, etc. showAll true // Fallback lint configuration (default severities, etc.) lintConfig file("default-lint.xml") // if true, generate a text report of issues (false by default) textReport true // location to write the output; can be a file or 'stdout' textOutput 'stdout' // if true, generate an XML report for use by for example Jenkins xmlReport false // file to write report to (if not specified, defaults to lint-results.xml) xmlOutput file("lint-report.xml") // if true, generate an HTML report (with issue explanations, sourcecode, etc) htmlReport true // optional path to report (default will be lint-results.html in the builddir) htmlOutput file("lint-report.html") // set to true to have all release builds run lint on issues with severity=fatal // and abort the build (controlled by abortOnError above) if fatal issues are found checkReleaseBuilds true // Set the severity of the given issues to fatal (which means they will be // checked during release builds (even if the lint target is not included) fatal 'NewApi', 'InlineApi' // Set the severity of the given issues to error error 'Wakelock', 'TextViewEdits' // Set the severity of the given issues to warning warning 'ResourceAsColor' // Set the severity of the given issues to ignore (same as disabling the check) ignore 'TypographyQuotes' } }
Android Gradle Plugin指南(四)——測試