使用AndroidStudio创建工程的时候总会发现自动构建出一个同名的包后面括号标注(AndroidTest)或者(Test)
所以就上网查了一些关于AndroidTest的文章
原文地址:http://blog.chinaunix.net/uid-20771867-id-121133.html
AndroidStudio下使用AndroidTest的英文书籍:http://pan.baidu.com/s/1skbOBrn (本书的Chapter11)```
Testing和Instrumentation
Android提供了一系列强大的测试工具,它针对Android的环境,扩展了业内标准的JUnit测试的框架,尽管你可以试用JUnit测试Android工程,但是Android工具允许你为应用程序的各方面进行更为复杂的测试,包括单元层面及框架层面.
Android测试环境的主要特征有:
- 可以访问Android系统对象.
- Instrumentation框架可以控制和测试应用程序.
- Android系统常用对象的模拟版本.
- 运行单个的Test或Test Suite的工具,带或不带Instrumentation
概要
Android测试环境的核心是一个Instrumentation框架,在这个框架下你的测试应用程序可以精确控制应用程序.试用Instrumentation,你可以在主程序启动之前,创建模拟的系统对象,如Context;控制应用程序的多个生命周期;发送UI事件给应用程序;在执行期间检查程序状态,.Instrumentation框架将通过主程序和测试程序运行在同一个进程来实现这些功能.
通通在测试工程的Manifest文件中添加元素来指定要测试的应用程序.这个元素的特性指明了要测试的应用程序包名,以及高速Android程序该如何运行测试程序,在InstrumentationTestRunner章节有更多的细节描述.
在Android中,测试程序也是Android程序,,因此它和被测试程序的书写方式,有很多相同的地方,SDK工具能帮助你同事创建主程序及它的测试工程,
TestingAPI
Android提供了基于JUnit测试框架的测试API来书写测试用例和测试程序.另外Android海提供强大的Instrumentation框架,允许测试用例访问程序的状态及运行时的对象.
下面的章节描述了Android测试中可利用的主要测试API.
JUnit TestCase类
继承自JUnit的TestCase,不能使用Instrumentation框架.但这些类包含访问系统对象(如Context)的方法,使用Context,你可以浏览资源,文件,数据库等等,基类是AndroidTestCase,一般常见的是它的子类,和特定的文件关联,
子类有
-
ApplicationTestCase:测试整个应用程序的类
它允许你注入一个模拟的Context到应用程序中,在应用程序启动之前初始化测试参数,并在应用程序结束之后销毁之前检查应用程序. -
ProviderTestCase2:测试单个ContentProvider的类
因为它要求使用MockContentRosolver,并注入一个IsolateContext,因此Provider的测试是与OS孤立的 -
ServiceTestCase:测试单个Service类
你可以注入一个模拟的Context或者Application(或者两者),或者让Android为你提供Context和MockApplication.
InstrumentationTestCase类
继承自Junit的TestCase,并可以使用Instrumentation框架,用于测试Activity,试用Instrumentation,Android可以向程序发送事件来自动进行UI测试,并可以精确控制Activity的启动,监测Activity的生命周期状态,
基类是InstrumentationTestCase,它的所有子类都能发送按键或者触摸事件给UI,子类还可以注入一个模拟的Intent,
子类有
- ActivityTestCase:Activity测试类的基类
-
SingleLunchActivityTestCase:测试单个的Activity的类,它能出发一次
setUp(),和tearDown(),而不是每个方法调用时都触发,如果你的测试方法都是针对同一个Activity的话,那就试用它吧 - SyncBaseInstrumentation:测试ContentProvider同步的类,它用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类包含关于AndroidView的有用断言方法,如asserHasScreenCoordinates(View view,int ,int),,可以测试View在可视区域的特定X,Y的位置,这些Assert简化了UI中几何图形和对其方式的测试,
Mock对象类
Android有一些类可以方便的创建模拟的系统对象,如Application,Context,ContentProvider和Resource,Android还在一些测试类中提供了一些方法来创建模拟的Intent,因为这些模拟器的对象比实际对象更容易使用,因此,试用它们能简化依赖注入,你可以在android.test和android.test.mock中找到这些类
它们是
- IsolateContext:模拟一个Context,这样应用程序可以孤立运行,与此同时,还有大量的代码帮助我们完成与Context的通信,这个类在单元测试时很有用,
- RenamingDelegatingContext:当修改默认文件和数据库名时,可以委托大多数的函数到一个存在的,常规的Context上,试用这个类来测试文件和数据库与正常系统Context之间的操作
- MockApplication,MockContentResolver,MockContext,MockDialogInterface,MockPackageManager,MockResources:创建模拟的系统对象的类,它们只暴露那些对对象的管理有用的方法,这些方法的默认实现只是抛出异常,你需要继承这些类,并重写这些方法.
InstrumentationTestRunner
Android提供了自定义的运行测试用例的类,叫做InstrumentationTestRunner.这个类控制应用程序处于测试环境中,在同一个进程中运行测试程序和主程序,,并将测试结果输出到合适的地方,InstrumentationTestRunner在运行是对整个运行环境的控制能力的关键是试用Instrumentation,注意,如果你的测试类不使用Instrumentation的话,你也可以用这个TestRunner,
当你运行一个测试程序时,首先会运行一个系统工具叫做ActivityManager,ActivityManager使用Instrumentation框架,来启动和控制TestRunner,这个TestRunner反过来又使用Instrumentation来关闭任何主程序的实例,然后启动测试程序和主程序(在同一个进程中,),这样能确保测试程序和主程序的直接交互,
在测试环境中工作
对Android程序的测试都包含在一个测试程序里,它本身也是一个Android应用程序,测试程序以单独的Android工程存在,与正常的Android程序有相同的文件和文件夹,测试工程在Manifest中指定要测试的Android应用程序,
每个测试程序包含一个或多个针对特定类型组件的测试用例.测试用例里定义了测试应用程序某些部分的测试方法,当你运行测试程序,Android会在相同的进程里加载主程序,然后出发每个测试用例里的测试方法,
测试工程
为了开始对一个Android程序测试,你需要使用Android工具创建一个测试工程,工具会创建工程文件夹,文件和所需要的子文件夹,工具还会创建一个Manifest文件,指定被测试的应用程序,
测试用例
一个测试程序包含一个或多个测试用例,它们都继承自AndroidTestCase类,选择一个测试用例取决于你要测试的Android组件的类型以及你要作什么样的测试,一个测试程序可以测试不同的组件,但每个测试用例类类设计时只能测试单一类型的组件,
一些Android组件有多个关联的测试用例类,在这种情况下可以选择,类间,你需要判你要进行的测试类型,例如对于Activity来说,你有两个选择,ActivityInstrumentationTestCase2,和ActivityUnitTestCase,
AndroidInstrumentationTestCase2设计用于设计一些功能性的测试,因此它在一个正常的系统环境中测试Activity,你可以注入Intent,但不能是模拟的Context,一般来说你不能模拟Activity之间的以来关系,
相比而言,ActivityUnitTestCase设计用于单元测试,因此它在一个孤立的系统环境中测试Activity,换句话说,当你用这个测试类时,Activity不能与其他的Activity交互,
作为一个经验法则,如果想测试Activity与Android之间的交互的话,使用AndroidInstrumentationTestCase2,如果想对一个Activity作回归测试的话,使用AndroidUnitTestCase,
测试方法
每个测试用例提供了可以建立测试环境和控制应用程序的方法,例如所有的测试用例类都提供了JUnit的setUp()方法,来搭建测试环境,另外,你可以添加方法来定义单独的测试,,当你运行测试程序时,每个添加的方法都运行一次,如果你重写了setUp方法,它会在每个方法运行前运行,相似的tearDown()方法会在每个方法运行后运行,
测试用例提供了大量的对组件启动和停止控制的方法,由于这个原因,在运行测试之前,你需要明确告诉Android启动一个组件,例如你可以用getActivity()来启动一个Activity,在整个测试用例期间,你只能调用这个方法一次,或者每个测试方法一次,甚至你可以在单个的测试方法中,用它的finishing()来销毁Activity,然后再调用getActivity()重新启动一个,
运行测试并查看结果
编译完测试工程后，你就可以使用系统工具Activity Manager来运行测试程序。你给Activity Manager提供了TestRunner的名（一般是InstrumentationTestRunner，在程序中指定）；名包括被测试程序的包名和TestRunner的名。Activity Manager加载并启动你的测试程序，杀死主程序的任何实例，然后在测试程序的同一个进程里加载主程序，然后传递测试程序的第一个测试用例。这个时候，TestRunner会接管这些测试用例，运行里面的每个测试方法，直到所有的方法运行结束
