阅读本文大约需要6.66分钟
Google提供的编写单元、功能、性能测试案例的类，通常可以细分为以下几个类：
ActivityInstrumentationTestCase2
这个类提供了一个单一的Activity的功能测试。Activity的测试，将使用系统创建的基础设施（通过调用InstrumentationTestCase.launchActivity()）来创建,且您能够直接对Activiy进行操作。
这个测试案例支持的其他选项包括：
- 您可以在UI线程运行任何测试方法 （见UiThreadTest）。
- 您可以注入自定义的Intent到你的Activity（见 setActivityIntent(Intent)）。
- 该类取代了ActivityInstrumentationTestCase，它被废弃了。新的测试应该使用这个基类来写。
ActivityUnitTestCase
这个类提供了一个单一的Activity独立测试。Activity的测试，将用最小的连接到系统的基础设施来创建，您可以注入mocked或包装Activity所依赖的许多版本（原文： wrappered versions of many of Activity’s dependencies 暂不理解其含义）。大部分的工作都是通过通过setUp()和tearDown() 自动处理的。
必须指出的是，作为一个真正的单元测试，您的Activity将不会在正常的系统运行，并且将不参加与其它Activity的正常相互作用。下面的方法在这个配置中，不应该被调用 - 它们大多会抛出异常：
以下方法可以调用，但不会做任何事情。出于测试目的，您可以使用getStartedActivityIntent()，并getStartedActivityRequest()方法来检查它们被调用时所携带的参数。
以下方法可以调用，但不会做任何事情。出于测试目的，您可以使用isFinishCalled()，并getFinishedActivityRequest()检查它们被调用时所携带的参数。
AndroidTestCase
如果您需要访问资源文件或其他依赖于Activity上下文Context 的东西时，可以继承这个类。
ApplicationTestCase
这个测试案例提供了一个框架，使您可以在受控环境中测试应用程序类。它提供了应用程序的生命周期 ，可以注入各种依赖的钩子以及控制您的被测应用程序的测试环境的基本支持。
生命周期支持。 每个应用程序被设计为方法调用的特定序列内（见Application有详细介绍）。为了支持应用程序的生命周期，这个测试用例将在以下时间被调用。
- 测试用例不会调用onCreate()，直到测试中调用了 createApplication()方法。这使得在onCreate被调用之前，您可以设置额外的框架或测试逻辑。
- 测试完成后，测试案例的tearDown()方法被自动调用，并且它将调用onDestroy()方法来暂停或销毁应用程序。
依赖注入。 每个应用程序都有一个内在的相关性，即Context。该框架允许你注入一个修改，模拟或隔离，这种相关性更换，从而进行真正的单元测试。
如果只是运行测试，你的应用程序将被注入全功能的Context。您可以在调用 createApplication() 之前，创建并通过调用 setContext()来注入Contexts的替代类。测试框架提供了一些上下文的替代品，其中包括MockContext， RenamingDelegatingContext，和 ContextWrapper。
InstrumentationTestCase
一个能够访问Instrumentation的测试用例
ProviderTestCase
如果你想使用 InstrumentationTestCase来测试一个单一的内容提供者content provider ，这个类的setUp()和 tearDown()提供了一些模板（测试content provider 的必要前提）。
ServiceTestCase
这个测试案例提供了一个框架，使你可以在受控环境中测试服务类。它提供了一个服务的生命周期的基本支持，以及可以注入各种依赖关系的钩子，并控制在您的服务测试环境。
生命周期支持。 A服务与调用的特定顺序访问，为中描述的 服务 文档。为了支持服务的生命周期， ServiceTestCase强制执行此协议：
- 该setUp()方法是每个测试方法之前调用。基实现获取系统环境。如果覆盖setUp()，您必须在覆盖的第一条语句调用 super.setUp()。
- 直到你的测试调用startService(Intent)或bindService(Intent)，测试用例才调用onCreate() 。这使得在服务运行之前，您可以设置或调整任何额外的框架或测试逻辑。
- 当任一测试方法调用ServiceTestCase.startService() 或ServiceTestCase.bindService()时， Service.onCreate()被调用。 Service.startService(Intent)或 Service.bindService(Intent, ServiceConnection, int)可以根据需要调用。它还存储需要被跟踪的值，也支持生命周期。
- 每个测试方法完成之后 ，测试用例调用tearDown()方法。这个方法根据服务的启动方式，适当地停止或销毁服务 。如果要重写tearDown()，你必须在重写方法中的最后一条语句 调用 super.tearDown()。
依赖注入。 一个服务有两个内在的相关性，其Context及其关联Application。该ServiceTestCase框架允许你修改注入，模拟或隔离，替代这些依赖，从而在一个孤立的环境控制的依赖进行单元测试。
默认情况下，测试案例被注入一个完整的系统环境和通用 MockApplication对象。您可以在调用startService()或bindService()之前，通过调用 setContext()或setApplication() 注入替代。测试框架提供了一些上下文的替代品，其中包括 MockContext，RenamingDelegatingContext， ContextWrapper，和 IsolatedContext。
SingleLaunchActivityTestCase
如果您想使用InstrumentationTestCase] 测试一个单一的Activity，这个类在setUp()和tearDown()中提供了一些启动和结束Activity的模板。这个类整个测试过程中，只启动一次Activity，而不是在每一次 setup / teardown都调用。