android基礎知識12：android自動化測試06—Instrumentation 05 InstrumentationTestRunner

        在學習Android、JUnit的過程中，隨著學習的深入，發現相關的內容越來越多，將這些類按照繼承關係整理如下：

• Test—TestCase—AndroidTestCase
• Test—TestCase—InstrumentationTestCase
• Test—TestSuite—InstrumentationTestSuite
• TestListener—–BaseTestRunner—AndroidTestRunner
• Instrumentation—InstrumentationTestRunner

        前4條路線是Android在JUnit架構上的擴充，最後一條線是一條重要的線，用一句話來說明就是：這是Android在JUnit架構的基礎上錦上添花。在android.app.instrumentation篇幅的學習中，我們對instrumentation有了一定的瞭解，本篇幅我們將介紹最後一個類InstrumentationTestRunner。在學習這個類前，我們先補充一些知識：在前面學習了這麼多，但是在我們的測試例子中卻沒有看到核心類InstrumentationTestSuite (這個類相當於測試單元中的容器，所有的TestCase都需要添加帶TestSuite中加以管理)，這是為什麼了？因為在Android
SDK中對這部分有著一層很深的“封裝”，正是有了這個中介層，所以我們沒有看到TestSuite這個容器，下面開始介紹這個中介層。

android.test.suitebuilder

        包的名稱似乎就在告訴我們這個包的作用：suite產生器，其包結構如下：

從這個圖上似乎沒有看到我們想要的，下面我們再仔細看下TestSuiteBuilder這個類：

         通過上面的關鍵字：Exclude(排除; 不包括在內)，Include(包括, 包含)，the given packages and all sub-package(給定的包和所有子包)，這些都讓我們感覺到TestSuiteBuilder類的主要作用是：將包添加或排除在當前的單元測試中。大家是不想起來了如何啟動單元測試篇幅中介紹的啟動命令：

adb shell am instrument -w com.xmobileapp.hello/android.test.InstrumentationTestRunner

這條命令的實際作用是是將com.xmobileapp.hello添加到當前單元測試中，在這裡我們在列舉一些這樣的命令，如下：
運行某個TestCase：

adb shell am instrument -w -e class com.android.foo.FooTest com.android.foo/android.test.InstrumentationTestRunner

運行一個TestCase中的某個功能：

adb shell am instrument -w -e class com.android.foo.FooTest#testFoo com.android.foo/android.test.InstrumentationTestRunner

同時測試多個TestCase：

adb shell am instrument -w -e class com.android.foo.FooTest,com.android.foo.TooTest com.android.foo/android.test.InstrumentationTestRunner

         看了這些命令，再結合TestSuiteBuilder的函數，我想大家就明白了一個重要的問題：在AndroidManifest.XML檔案Instrumentation的屬性（如所示）中為什麼沒有任何與TestSuite相關的說明?

        單元測試的配置已經取代了TestCase的管理，所以TestSuite的功能就弱化了很多，TestSuiteBuilder就是在我們提供當前測試的測試範圍的配置，例如：是否將某個TestCase添加到當前測試中。TestSuiteBuilder類的函數builder就根據的我們的配置產生TestSuite。看到這裡我們的的疑惑就少了很多，下面我們繼續介紹InstrumentationTestRunner類。

InstrumentationTestRunner 類結構，如所示：

主要函數介面列舉如下：

InstrumentationTestRunner典型的使用過程：

1. 編寫測試案例，測試案例基本上是從以下類繼承的；
   l ActivityInstrumentationTestCase
   ActivityUnitTestCase
   AndroidTestCase
   ApplicationTestCase
   InstrumentationTestCase
   ProviderTestCase
   ServiceTestCaseSingleLaunchActivityTestCase
2. 在AndroidManifest.xml中定義一個instrumentation並targetPackage屬性中說明被測試的包名稱;
3. 運行instrumentation使用“adb shell am instrument -w”，運行所有測試（除效能測試）;
4. 運行instrumentation使用“adb shell am instrument -w”，並添加額外的命令“-e func true’”來運行所有的功能測試。這謝測試繼承至測InstrumentationTestCase;
5. 運行instrumentation使用“adb shell am instrument -w”，並添加額外的命令“-e unit true”來運行所有的單元測試。這些測試那些非InstrumentationTestCase 從繼承的類;
6. 運行instrumentation使用“adb shell am instrument -w”，並添加額外的命令“-e class” 來運行某個單獨的TestCase。

看了上面的命令，我們在看下ApiDemos\test\…\AllTests.java中的一些注釋，如下：

大家就應該明白這些注釋說的是什麼意思了吧，這篇文章的目的也就達到了。
下面介紹一個簡要的例子：

public class ApiDemosRunner extends InstrumentationTestRunner {@Overridepublic TestSuite getAllTests(){Log.i(“ApiDemosRunner”, “ApiDemosRunner::getAllTests()”);return new TestSuiteBuilder(ApiDemosRunner.class).includeAllPackagesUnderHere().build();}@Overridepublic ClassLoader getLoader(){return ApiDemosRunner.class.getClassLoader();}}

         看了這段代碼，大家就明白TestSuiteBuilder的主要作用了，這裡我們需要說明的：萬變不離其中，整個測試的核心還是TestSuite，只不過Android SDK在此基礎上增加了TestSuiteBuilder，是我們對TestCase的管理更加方便。InstrumentationTestRunner類相對比較簡單，看了上面的例子，以後按照這種方法使用就可以了，這裡就不在詳細說明。

總結說明

Android SDK在單元測試方面的封裝比較完美，我們幾乎不需要寫太多的代碼就可以完成單元測試。

參考資料：

android.test.InstrumentationTestRunner解析