android.test.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.FooTestcom.android.foo/android.test.InstrumentationTestRunner

运行一个TestCase中的某个功能：
adb shell am instrument -w -e classcom.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相关的说明?

单元测试的配置已经取代了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。

看了上面的命令，我们在看下ApiDemostest…AllTests.java中的一些注释，如下：

大家就应该明白这些注释说的是什么意思了吧，这篇文章的目的也就达到了。
下面介绍一个简要的例子：

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

@Override
publicClassLoadergetLoader()
{
return ApiDemosRunner.class.getClassLoader();
}
}
看了这段代码，大家就明白TestSuiteBuilder的主要作用了，这里我们需要说明的：万变不离其中，整个测试的核心还是TestSuite，只 不过Android SDK在此基础上增加了TestSuiteBuilder，是我们对TestCase的管理更加方便。 InstrumentationTestRunner类相对比较简单，看了上面的例子，以后按照这种方法使用就可以了，这里就不在详细说明。

总结说明

Android SDK在单元测试方面的封装比较完美，我们几乎不需要写太多的代码就可以完成单元测试。