android測試關係

 

在學習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產生器，其包結構如下：

2011-6-24 17:49:30 上傳

下載附件
(23.85 KB)

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

2011-6-24 17:49:37 上傳

下載附件
(64.49 KB)

通過上面的關鍵字：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.FooTestcom.android.foo/android.test.InstrumentationTestRunner

運行一個TestCase中的某個功能：
adb shell am instrument -w -e class com.android.foo.FooTest#testFoocom.android.foo/android.test.InstrumentationTestRunner

同時測試多個TestCase：
adb shell am instrument -w -e classcom.android.foo.FooTest,com.android.foo.TooTestcom.android.foo/android.test.InstrumentationTestRunner

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

2011-6-24 17:49:34 上傳

下載附件
(12.21 KB)

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

InstrumentationTestRunner 類結構，如所示：

2011-6-24 17:49:33 上傳

下載附件
(42.95 KB)

主要函數介面列舉如下：

2011-6-24 17:49:31 上傳

下載附件
(24.66 KB)

InstrumentationTestRunner典型的使用過程：

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

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

2011-6-24 17:49:35 上傳

下載附件
(58.66 KB)

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

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

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

總結說明

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