Testing和Instrumentation

Android提供了一系列强大的测试工具，它针对Android的环境，扩展了业内标准的JUnit测试框架。尽管你可使用JUnit测试Android工程，但Android工具容许你为应用程序的各个方面进行更为复杂的测试，包括单元层面及框架层面。

Android测试环境的主要特征有：

• 能够访问Android系统对象。

• Instrumentation框架能够控制和测试应用程序。

• Android系统经常使用对象的模拟版本。

• 运行单个test或test suite的工具，带或不带Instrumentation。

• 支持以Eclipse的ADT插件和命令行方式管理Test和Test工程。

这篇文章是对Android测试环境和测试方法的简要介绍，并假设你已经拥有必定的Android应用程序编程及JUnit测试的经验。

概要

Android测试环境的核心是一个Instrumentation框架，在这个框架下，你的测试应用程序能够精确控制应用程序。使用Instrumentation，你能够在主程序启动以前，建立模拟的系统对象，如Context；控制应用程序的多个生命周期；发送UI事件给应用程序；在执行期间检查程序状态。Instrumentation框架经过将主程序和测试程序运行在同一个进程来实现这些功能。

经过在测试工程的manifest文件中添加<instrumentation>元素来指定要测试的应用程序。这个元素的特性指明了要测试的应用程序包名，以及告诉Android如何运行测试程序。在Inustrumentation TestRunner章节有更多的细节描述。

下面的图片概要的描述了Android的测试环境：

在Android中，测试程序也是Android程序，所以，它和被测试程序的书写方式有不少相同的地方。SDK工具能帮助你同时建立主程序工程及它的测试工程。你能够经过Eclipse的ADT插件或者命令行来运行Android测试。Eclipse的ADT提供了大量的工具来建立测试用例，运行以及查看结果。

Testing API

Android提供了基于JUnit测试框架的测试API来书写测试用例和测试程序。另外，Android还提供了强大的Instrumentation框架，容许测试用例访问程序的状态及运行时对象。

下面的章节描述了Android中可利用的主要测试API。

JUnit TestCase类

继承自JUnit的TestCase，不能使用Instrumentation框架。但这些类包含访问系统对象（如Context）的方法。使用Context，你能够浏览资源，文件，数据库等等。基类是AndroidTestCase，通常常见的是它的子类，和特定组件关联。

子类有：

• ApplicationTestCase——测试整个应用程序的类。它容许你注入一个模拟的Context到应用程序中，在应用程序启动以前初始化测试参数，并在应用程序结束以后销毁以前检查应用程序。

• ProviderTestCase2——测试单个ContentProvider的类。由于它要求使用MockContentResolver，并注入一个IsolatedContext，所以Provider的测试是与OS孤立的。

• ServiceTestCase——测试单个Service的类。你能够注入一个模拟的Context或模拟的Application（或者二者），或者让Android为你提供Context和MockApplication。

Instrumentation TestCase类

继承自JUnit TestCase类，并可使用Instrumentation框架，用于测试Activity。使用Instrumentation，Android能够向程序发送事件来自动进行UI测试，并能够精确控制Activity的启动，监测Activity生命周期的状态。

基类是InstrumentationTestCase。它的全部子类都能发送按键或触摸事件给UI。子类还能够注入一个模拟的Intent。

子类有：

• ActivityTestCase——Activity测试类的基类。

• SingleLaunchActivityTestCase——测试单个Activity的类。它能触发一次setup()和tearDown()，而不是每一个方法调用时都触发。若是你的测试方法都是针对同一个Activity的话，那就使用它吧。

• SyncBaseInstrumentation——测试Content Provider同步性的类。它使用Instrumentation在启动测试同步性以前取消已经存在的同步对象。

• ActivityUnitTestCase——对单个Activity进行单一测试的类。使用它，你能够注入模拟的Context或Application，或者二者。它用于对Activity进行单元测试。

不一样于其它的Instrumentation类，这个测试类不能注入模拟的Intent。

• ActivityInstrumentationTestCase2——在正常的系统环境中测试单个Activity的类。你不能注入一个模拟的Context，但你能够注入一个模拟的Intent。另外，你还能够在UI线程（应用程序的主线程）运行测试方法，而且能够给应用程序UI发送按键及触摸事件。

Assert类

Android还继承了JUnit的Assert类，其中，有两个子类，MoreAsserts和ViewAsserts：

• MoreAsserts类包含更多强大的断言方法，如assertContainsRegex(String, String)，能够做正则表达式的匹配。

• ViewAsserts类包含关于Android View的有用断言方法，如assertHasScreenCoordinates(View, View, int, int)，能够测试View在可视区域的特定X、Y位置。这些Assert简化了UI中几何图形和对齐方式的测试。

Mock对象类

Android有一些类能够方便的建立模拟的系统对象，如Application，Context，Content Resolver和Resource。Android还在一些测试类中提供了一些方法来建立模拟的Intent。由于这些模拟的对象比实际对象更容易使用，所以，使用它们能简化依赖注入。你能够在android.test和android.test.mock中找到这些类。

它们是：

• IsolatedContext——模拟一个Context，这样应用程序能够孤立运行。与此同时，还有大量的代码帮助咱们完成与Context的通讯。这个类在单元测试时颇有用。

• RenamingDelegatingContext——当修改默认的文件和数据库名时，能够委托大多数的函数到一个存在的、常规的Context上。使用这个类来测试文件和数据库与正常的系统Context之间的操做。

• MockApplication,MockContentResolver,MockContext,MockDialogInterface,MockPackageManager,MockResources——建立模拟的系统对象的类。它们只暴露那些对对象的管理有用的方法。这些方法的默认实现只是抛出异常。你须要继承这些类并重写这些方法。

Instrumentation TestRunner

Android提供了自定义的运行测试用例的类，叫作InstrumentationTestRunner。这个类控制应用程序处于测试环境中，在同一个进程中运行测试程序和主程序，而且将测试结果输出到合适的地方。IntrumentationTestRunner在运行时对整个测试环境的控制能力的关键是使用Instrumentation。注意，若是你的测试类不使用Instrumentation的话，你也可使用这个TestRunner。

当你运行一个测试程序时，首先会运行一个系统工具叫作Activity Manager。Activity Manager使用Instrumentation框架来启动和控制TestRunner，这个TestRunner反过来又使用Intrumentation来关闭任何主程序的实例，而后启动测试程序及主程序（同一个进程中）。这就能确保测试程序与主程序间的直接交互。

在测试环境中工做

对Android程序的测试都包含在一个测试程序里，它自己也是一个Android应用程序。测试程序以单独的Android工程存在，与正常的Android程序有着相同的文件和文件夹。测试工程经过在manifest文件中指定要测试的应用程序。

每一个测试程序包含一个或多个针对特定类型组件的测试用例。测试用例里定义了测试应用程序某些部分的测试方法。当你运行测试程序，Android会在相同进程里加载主程序，而后触发每一个测试用例里的测试方法。

测试工程

为了开始对一个Android程序测试，你须要使用Android工具建立一个测试工程。工具会建立工程文件夹、文件和所需的子文件夹。工具还会建立一个manifest文件，指定被测试的应用程序。

测试用例

一个测试程序包含一个或多个测试用例，它们都继承自Android TestCase类。选择一个测试用例类取决于你要测试的Android组件的类型以及你要作什么样的测试。一个测试程序能够测试不一样的组件，但每一个测试用例类设计时只能测试单一类型的组件。

一些Android组件有多个关联的测试用例类。在这种状况下，在可选择的类间，你须要判断你要进行的测试类型。例如，对于Activity来讲，你有两个选择，ActivityInstrumentationTestCase2和ActivityUnitTestCase。

ActivityInstrumentationTestCase2设计用于进行一些功能性的测试，所以，它在一个正常的系统环境中测试Activity。你能够注入模拟的Intent，但不能是模拟的Context。通常来讲，你不能模拟Activity间的依赖关系。

相比而言，ActivityUnitTestCase设计用于单元测试，所以，它在一个孤立的系统环境中测试Activity。换句话说，当你使用这个测试类时，Activity不能与其它Activity交互。

做为一个经验法则，若是你想测试Activity与Android的交互的话，使用ActivityInstrumentationTestCase2。若是你想对一个Activity作回归测试的话，使用ActivityUnitTestCase。

测试方法

每一个测试用例类提供了能够创建测试环境和控制应用程序的方法。例如，全部的测试用例类都提供了JUnit的setUp()方法来搭建测试环境。另外，你能够添加方法来定义单独的测试。当你运行测试程序时，每一个添加的方法都会运行一次。若是你重写了setUp()方法，它会在每一个方法运行前运行。类似的，tearDown()方法会在每一个方法以后运行。

测试用例类提供了大量的对组件启动和中止控制的方法。因为这个缘由，在运行测试以前，你须要明确告诉Android启动一个组件。例如，你可使用getActivity()来启动一个Activity。在整个测试用例期间，你只能调用这个方法一次，或者每一个测试方法一次。甚至你能够在单个测试方法中，调用它的finishing()来销毁Activity，而后再调用getActivity()从新启动一个。

运行测试并查看结果

编译完测试工程后，你就可使用系统工具Activity Manager来运行测试程序。你给Activity Manager提供了TestRunner的名（通常是InstrumentationTestRunner，在程序中指定）；名包括被测试程序的包名和TestRunner的名。Activity Manager加载并启动你的测试程序，杀死主程序的任何实例，而后在测试程序的同一个进程里加载主程序，而后传递测试程序的第一个测试用例。这个时候，TestRunner会接管这些测试用例，运行里面的每一个测试方法，直到全部的方法运行结束。

若是你使用Eclipse，结果会在JUnit的面板中显示。若是你使用命令行，将输出到STDOUT上。

测试什么？

除了一些功能测试外，这里还有一些你应该考虑测试的内容：

• Activity生命周期事件：你应该测试Activity处理生命周期事件的正确性。例如，一个Activity应该在pause或destroy事件时保存它的状态。记住一点的是屏幕方向的改变也会引起当前Activity销毁，所以，你须要测试这种偶然状况确保不会丢失应用程序状态。

• 数据库操做：你应该确保数据库操做能正确处理应用程序状态的变化。使用android.test.mock中的模拟对象。

• 屏幕大小和分辨率：在发布程序以前，确保在全部要运行的屏幕大小和分辨率上测试经过。你可使用AVD来测试，或者使用真实的目标设备进行测试。

附加：UI测试

接下来的章节为应用程序UI的测试提供了一些提示，特别是帮助你在UI线程里处理动做，触屏和按键事件，和锁屏。

UI线程中测试

Activity运行在程序的UI线程里。一旦UI初始化后，例如在Activity的onCreate()方法后，全部与UI的交互都必须运行在UI线程里。当你正常运行程序时，它有权限能够访问这个线程，而且不会出现什么特别的事情。

当你运行测试程序时，这一点发生了变化。在带有instrumentation的类里，你能够触发方法在UI线程里运行。其它的测试用例类不容许这么作。为了一个完整的测试方法都在UI线程里运行，你可使用@UIThreadTest来声明线程。注意，这将会在UI线程里运行方法里全部的语句。不与UI交互的方法不容许这么作；例如，你不能触发Instrumentation.waitForIdleSync()。

若是让方法中的一部分代码运行在UI线程的话，建立一个匿名的Runnable对象，把代码放到run()方法中，而后把这个对象传递给appActivity.runOnUiThread()，在这里，appActivity就是你要测试的app对象。

例如，下面的代码实例化了一个要测试的Activity，为Spinner请求焦点，而后发送一个按键给它。注意：waitForIdleSync和sendKeys不容许在UI线程里运行：

  private MyActivity mActivity; // MyActivity is the class name of the app under test 

  private Spinner mSpinner; 

 

  ... 

 

  protected void setUp() throws Exception { 

      super.setUp(); 

      mInstrumentation = getInstrumentation(); 

 

      mActivity = getActivity(); // get a references to the app under test 

 

      /* 

       * Get a reference to the main widget of the app under test, a Spinner 

       */ 

      mSpinner = (Spinner) mActivity.findViewById(com.android.demo.myactivity.R.id.Spinner01); 

 

  ... 

 

  public void aTest() { 

      /* 

       * request focus for the Spinner, so that the test can send key events to it 

       * This request must be run on the UI thread. To do this, use the runOnUiThread method 

       * and pass it a Runnable that contains a call to requestFocus on the Spinner. 

       */ 

      mActivity.runOnUiThread(new Runnable() { 

          public void run() { 

              mSpinner.requestFocus(); 

          } 

      }); 

 

      mInstrumentation.waitForIdleSync(); 

 

      this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);

 

关闭触屏模式

为了控制从测试程序中发送给模拟器或设备的按键事件，你必须关闭触屏模式。若是你不这么作，按键事件将被忽略。

关闭触摸模式，你须要在调用getActivity()启动Activity以前调用ActivityInstrumentationTestCase2.setActivityTouchMode(false)。你必须在非UI线程中运行这个调用。基于这个缘由，你不能在声明有@UIThread的测试方法调用。能够在setUp()中调用。

模拟器或设备的解锁

你可能已经发现，若是模拟器或设备的键盘保护模式使得HOME画面不可用时，UI测试不能正常工做。这是由于应用程序不能接收sendKeys()的事件。避免这种状况最好的方式是在启动模拟器或设备时关闭键盘保护模式。

你还能够显式地关闭键盘保护。这须要在manifest文件中添加一个权限，而后就能在程序中关闭键盘保护。注意，你必须在发布程序以前移除这个，或者在发布的程序中禁用这个功能。

在<manifest>元素下添加<uses-permission android:name=”androd.permission.DISABLE_KEYGUARD”/>。为了关闭键盘保护，在你测试的Activity的onCreate()方法中添加如下代码：

  mKeyGuardManager = (KeyguardManager)getSystemService(KEYGUARD_SERVICE); 

  mLock = mKeyGuardManager.newKeyguardLock("activity_classname"); 

  mLock.disableKeyguard();

这里，activity_classname是Activity的类名。