Android测试之设备化测试（Instrumented Tests）

最新推荐文章于 2024-01-22 20:27:23 发布

Java上下求索

最新推荐文章于 2024-01-22 20:27:23 发布

阅读量5.9k

点赞数 1

分类专栏： android

本文链接：https://blog.csdn.net/WZG_1987/article/details/52505649

版权

android 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

当我们需要使用到安卓框架的时候，也就是android.jar里面的api的时候，使用本地单元测试的方式就难以做到了。这时就要使用设备化的测试。

设备化测试分为

——设备化单元测试（Instrumented Unit Test）

——组件集成测试

——app集成测试。

以下是官网对这几种测试的特点简述和详细说明：

Building Instrumented Unit Tests: Build complex unit tests with Android dependencies that cannot be satisfied with mock objects.
Automating User Interface Tests: Create tests to verify that the user interface behaves correctly for user interactions within a single app or for interactions across multiple apps.
Testing App Component Integrations: Verify the behavior of components that users do not directly interact with, such as a Service or aContent Provider.

详细说明：

Type	Subtype	Description
Unit tests
	Local Unit Tests	Unit tests that run locally on the Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies.
	Instrumented unit tests	Unit tests that run on an Android device or emulator. These tests have access to `Instrumentation`information, such as the `Context` of the app you are testing. Use these tests when your tests have Android dependencies that mock objects cannot satisfy.
Integration Tests
	Components within your app only	This type of test verifies that the target app behaves as expected when a user performs a specific action or enters a specific input in its activities. For example, it allows you to check that the target app returns the correct UI output in response to user interactions in the app’s activities. UI testing frameworks like Espressoallow you to programmatically simulate user actions and test complex intra-app user interactions.
	Cross-app Components	This type of test verifies the correct behavior of interactions between different user apps or between user apps and system apps. For example, you might want to test that your app behaves correctly when the user performs an action in the Android Settings menu. UI testing frameworks that support cross-app interactions, such as UI Automator, allow you to create tests for such scenarios.

设备化测试的类需要放在module-name/src/androidTests/java/这个目录下，类名和包名没有要求，但如果是suite类型的测试类，包名通常用.suite结尾。

对于支持到JUnit4的gradle版本，我们只需要按照junit4的写法来就可以了，关于这方面，可以参考另一篇博文。

下面讲一讲各种类型的设备化测试的基本实现流程：

设备化单元测试

首先，你需要引入以下依赖：

dependencies {
    androidTestCompile 'com.android.support:support-annotations:24.0.0'
    androidTestCompile 'com.android.support.test:runner:0.5'
    androidTestCompile 'com.android.support.test:rules:0.5'
    // Optional -- Hamcrest library
    androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
    // Optional -- UI testing with Espresso
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
    // Optional -- UI testing with UI Automator
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
}

如果你其它地方有引用到 support-annotations 这个包的话，那么它的版本有可能会跟着几个包所引用到的annotations包版本冲突，这时候可以把上面第一个引入删掉，并且对其它几个包都这样配置一下（就是去掉它们里面的这个包的依赖的意思）：

androidTestCompile ('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})

然后，你还需要在你当前需要测试的module的build.gradle文件里加入这个配置：

android {
    defaultConfig {
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
}

最后是代码部分，除了按照junit4的写法添加方法和注解外，只需要在类上添加一个@RunWith(AndroidJUnit4.class) 这样的注解。这样就可以在test方法里面调用安卓api的方法了。

组件集成测试

这个包括Service和ContentProvider的测试，支持进程间的通信。但不支持IntentService和广播。

其实Activity的集成测试也属于这部分，官方介绍时大概为了方便，直接只在app集成测试环节使用了activity的测试。其实也可以放到这里来，单个引用activity来做测试。

app集成测试部分只是综合使用了这几种引用模式。

其实这部分的话，除了上面单元测试的那几步都要以外，只要再加一个这样的申明就差不多了：

@Rule
public ActivityTestRule<OneFlagActivity> mActivityRule = new ActivityTestRule<>(OneFlagActivity.class);//具体可看下面app集成测试的使用。

Service的集成测试跟单个应用内的测试比较相像。只不过把声明activity变成了声明service，不过没在声明的时候指定具体的service，而是在test方法里面再做绑定操作。

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

@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)));
}

这里的mServiceRule就相当于绑定service的那个activity。

App集成测试

这部分的测试是综合使用了上面的那些测试模式，尤其是activity的，让你引用activity的输入，模拟用户的ui操作。可以是应用内的操作，也可以跨应用操作。

嗯。。

给一段代码感受一下：

@Rule
public ActivityTestRule<OneFlagActivity> mActivityRule = new ActivityTestRule<>(OneFlagActivity.class);//该变量起了一个加载activity的作用，
                                                                                            // 不加的话就要在测试方法里面手动启动或者添加intent启动

@Test
public void mockClick(){
    ViewInteraction vi = onView(withId(R.id.tv_textborad));//1.找到ui组件
    vi.perform(click());//2.操作
    onView(withId(R.id.tv_textborad2)).check(matches(isDisplayed()));//3.判断结果
}