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

轉載處:http://blog.csdn.net/xianming01/article/details/7893553

在學習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類的主要作用是：将包添加或排除在目前的單元測試中。大家是不想起來了如何啟動單元測試篇幅中介紹的啟動指令：

[plain] view plaincopy

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

這條指令的實際作用是是将com.xmobileapp.hello添加到目前單元測試中，在這裡我們在列舉一些這樣的指令，如下：

運作某個TestCase：

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

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

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

同時測試多個TestCase：

1. 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中的一些注釋，如下：

大家就應該明白這些注釋說的是什麼意思了吧，這篇文章的目的也就達到了。

下面介紹一個簡要的例子：

[java] view plaincopy

1. public class ApiDemosRunner extends InstrumentationTestRunner   
2. {  
3. @Override  
4. public TestSuite getAllTests()  
6. Log.i(“ApiDemosRunner”, “ApiDemosRunner::getAllTests()”);  
7. return new TestSuiteBuilder(ApiDemosRunner.class)  
8. .includeAllPackagesUnderHere()  
9. .build();  
10. }  
12. public ClassLoader getLoader()  
14. return ApiDemosRunner.class.getClassLoader();  

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

總結說明

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