翻译官方文档-组件集成测试

官方文档链接：https://developer.android.google.cn/training/testing/integration-testing/index.html

1.前言

---

如果应用程序使用用户不直接交互的组件，例如Service或ContentProvider，则需要验证这些组件行为是正确的。当开发这些组件时，应该养成写集成测试的习惯，以便验证应用程序的组件运行于设备或模拟器上的行为。

注意：安卓并没有为BroadcastReceiver提供独立的测试用例类，若需验证它响应正确，可以给它发送Intent对象来测试。或者，可以通过调用InstrumentationRegistry.getTargetContext()方法创建BroadcastReceiver实例，然后调用它需测试的方法（通常，就是onReceive()方法）。

下面将介绍如何使用安卓平台提供的测试APIs和工具，来构建自动化集成测试。

2.测试Service

---

如果正在实现一个本地Service作为应用程序的组件，应该测试Service来确保不会出现意料之外的行为。可以创建设备单元测试来验证，Service中的行为是正确的；例如，Service存储和返回有效数据值，且正确地执行数据操作。

安卓测试支持库为独立测试Service对象提供API。ServiceTestRule类是JUnit 4规则，可以在单元测试方法运行前启动Service，并在测试完成后关闭Service。通过使用此测试规则，确保测试方法运行前，与Service的连接已经建立了。要了解更多关于JUnit 4规则，请参阅JUnit文档。

注意：ServiceTestRule类不支持IntentService对象的测试。如果需要测试IntentService对象，可以通过将逻辑封装到独立的类中，并创建相应的单元测试来代替。

2.1.设置测试环境

为Service构建集成测试之前，请确保项目已配置设备测试。

2.2.创建Service集成测试

集成测试应该写成JUnit 4测试类。要了解更多关于创建JUnit 4测试类和使用JUnit 4断言方法，请参阅创建设备单元测试类。为Service创建集成测试，在测试类定义之前添加 @RunWith(AndroidJUnit4.class)注解，还需要指定安卓测试支持库提供的AndroidJUnitRunner类作为默认测试运行器。在运行设备单元测试中有更详细的描述。

接着测试中，通过使用@Rule注解，创建ServiceTestRule实例。

@Rule
public final ServiceTestRule mServiceRule = new ServiceTestRule();

下面的示例展示，如何实现一个关于Service的集成测试。testWithBoundService()测试方法验证应用程序成功绑定本地Service，且Service接口行为正常。

@Test
public void testWithBoundService() throws TimeoutException {
    // Create the service Intent.
    Intent serviceIntent =
            new Intent(InstrumentationRegistry.getTargetContext(),
                LocalService.class);

    // Data can be passed to the service via the Intent.
    serviceIntent.putExtra(LocalService.SEED_KEY, 42L);

    // Bind the service and grab a reference to the binder.
    IBinder binder = mServiceRule.bindService(serviceIntent);

    // Get the reference to the service, or you can call
    // public methods on the binder directly.
    LocalService service =
            ((LocalService.LocalBinder) binder).getService();

    // Verify that the service is working correctly.
    assertThat(service.getRandomInt(), is(any(Integer.class)));
}

2.3.运行Service集成测试

可以从Android Studio或命令行运行集成测试，确认项目已指定AndroidJUnitRunner作为默认设备运行器。

3.测试ContentProvider

---

如果正在实现ContentProvider，来存储和检索数据或允许其它应用程序访问数据，应该测试它以确保不会出现意料之外的行为。下面描述如何测试公共的ContentProvider，也适用于私有的（仅提供给自己的应用程序）。

3.1.创建ContentProvider集成测试

在安卓中，应用程序将ContentProvider视为提供数据表的数据APIs，从而隐藏内部实现。ContentProvider可能有许多公共常量，但它通常即使有公共方法也很少，而且没有公共变量。为此，应该仅基于ContentProvider（被设计成在它和它的用户之间提供契约）的公共成员编写测试。

ContentProvider允许访问实际用户数据，所以确保在独立的测试环境下测试它是很重要的。这种方式可以只运行测试用例中显式设置的数据依赖，还意味着测试不会修改实际用户数据。例如，应该避免编写失败的测试，因为数据会遗留下来。类似的，测试应该避免通过ContentProvider添加或删除实际相关信息。借助ProviderTestCase2类独立测试ContentProvider，可以使用安卓模拟对象类（如IsolatedContext和MockContentResolver）来访问文件和数据库信息，而不影响实际用户数据。

集成测试应该写成JUnit 4测试类。要了解更多关于创建JUnit 4测试类和使用JUnit 4断言，请参阅创建本地单元测试类。为ContentProvider创建集成测试，必须执行下面的开发步骤：

• 创建测试类作为ProviderTestCase2的子类。

• 在测试类定义之前添加 @RunWith(AndroidJUnit4.class)注解。

• 指定安卓测试支持库提供的AndroidJUnitRunner类作为默认测试运行器。

• 根据InstrumentationRegistry类设置Context对象，请参阅下面的代码片段示例。

  @Override
  protected void setUp() throws Exception {
      super.setUp();
      setContext(InstrumentationRegistry.getTargetContext());
  }
  

3.2.ProviderTestCase2如何工作

用于测试ContentProvider的是ProviderTestCase2的子类，作为基类的它继承自AndroidTestCase，所以提供了JUnit测试框架和测试应用权限的安卓特定方法。这个类最重要的功能是它的初始化，能创建独立的测试环境。

初始化在ProviderTestCase2的构造函数中完成，它的子类在调用自己的构造函数时也会执行。ProviderTestCase2的构造函数会创建一个IsolatedContext对象，用于执行文件和数据库操作，但不引出其它与安卓系统的交互。因为操作发生在设备或模拟器的本地目录下，并有特定的前缀。接着，构造函数会为测试创建MockContentResolver来使用。最后，构造函数在测试时创建ContentProvider实例。这是普通的ContentProvider对象，但它是从IsolatedContext获取所需的环境信息，所以被限制在独立的测试环境下工作，测试用例类中的所有测试都是针对这个独立的对象运行的。

为ContentProvider运行集成测试的方式与设备单元测试相同，按照运行设备单元测试中描述的步骤。

3.3.测试的内容

下面是一些测试ContentProvider的具体指南。

• 用ContentResolver的方法测试：即使可以在ProviderTestCase2中实例化一个ContentProvider对象，也总该通过ContentResolver对象使用相应的URI来测试。这样做确保，通过执行与常规应用程序将使用的相同交互来测试ContentProvider。
• 公共的ContentProvider作为契约测试：如果想让ContentProvider对其它应用程序公开和有效，应该将它作为契约测试。下面给出如何做的一些例子：
  • 测试ContentProvider公开暴露的常量：例如，查询指向ContentProvider某数据表中列名的常量，它们应该总是由ContentProvider公开定义的。
  • 测试ContentProvider提供的所有URIs：ContentProvider可能提供几种URIs，每种涉及数据的不同方面。
  • 测试无效的URIs：单元测试应该有意使用无效URI调用ContentProvider，并查找错误。一个好的ContentProvider设计时，对于无效的URIs会抛出IllegalArgumentException异常。
• 标准的ContentProvider交互测试：大多数ContentProvider提供六种可访问方法，如query()、insert()、delete()、update()、getType()和onCreate()。测试应该验证上述所有方法是否有效，更详细的描述参考Content Providers。
• 业务逻辑测试：如果内容提供者实现业务逻辑，应该测试它。业务逻辑包括处理无效值，数据或算术计算，消除或合并重复。

4.总结

---

本文主要讲了如何测试用户看不见、摸不到的系统组件，包括Service和ContentProvider。系统组件是开发工作中经常用到的，可由于它们与系统息息相关，不太容易排除其它因素的影响，所以一定要注意使用提供的类创建独立环境下的对象。