1. AndroidX Test 框架概述
android.test 包全部升级、标准化,让你能在真实设备或模拟器上稳定运行单元测试、集成测试和 UI 测试。
1.1 什么是 AndroidX Test
AndroidX Test 其实是一组库的名字,说白了,它就是 Android 测试领域的新标准。我记得刚接手一个老项目时,里面还在用 InstrumentationTestRunner 和 ActivityUnitTestCase,各种兼容性问题折腾了我两天。后来切到 AndroidX Test,配置干净、API 整齐,问题少了一大半。
它的核心组成可以分为三层:
- 底层运行器——
AndroidJUnitRunner,负责在设备上驱动测试。 - 核心工具——
InstrumentationRegistry、ActivityScenario、FragmentScenario,帮你拿到 Context、启动 Activity 或 Fragment。 - 规则与扩展——一系列 JUnit4 Rule(如
ActivityScenarioRule),以及 Espresso、UI Automator 这类 UI 测试框架。
简单说,你写的一个 @Test 方法,通过 AndroidJUnitRunner 调度,在真实环境中完成验证。这就是 AndroidX Test 的工作方式。
1.2 为什么需要回归测试
做 Android 开发的都懂:改一行代码,UI 变个布局,很可能就把某个隐藏的 NullPointerException 给引出来了。我之前一个电商项目,每次迭代都要手动测试几十个页面,耗时长还容易漏。后来引入自动化回归测试,每天晚上跑一次,第二天早上看报告,基本没有“漏网之鱼”。
回归测试的价值我总结为三点:
- 快速验证已有功能不受破坏——哪怕你只是改了个字体颜色,也得确认支付流程没崩。
- 减少人工重复劳动——同样场景跑一百遍,不如让机器跑一百遍。
- 定位问题效率高——失败的用例会告诉你“哪个页面、哪个操作挂了”,比手动摸索快得多。
1.3 框架组成一览
AndroidX Test 不是一个单一的 jar 包,而是一个“家族”。我在项目中常用的组件如下表:
| 组件名称 | artifact ID | 主要作用 | 我个人的使用频率 |
|---|---|---|---|
| AndroidJUnitRunner | androidx.test:runner | 测试运行器,控制测试案例在设备上的执行 | 每个项目必用 |
| Core | androidx.test:core | 提供 InstrumentationRegistry、ActivityScenario 等基础 API | 几乎每个测试类都会引入 |
| Rules | androidx.test:rules | 包含 ActivityScenarioRule、ServiceTestRule 等 JUnit4 规则 | 视场景而定,UI 测试必用 |
| Ext JUnit | androidx.test.ext:junit | JUnit4 扩展(如 @RunWith(AndroidJUnit4.class)) | 所有测试类的标配 |
| Espresso | androidx.test.espresso:espresso-core | 强大的 UI 交互与断言库 | UI 回归测试的主力 |
| UI Automator | androidx.test.uiautomator:uiautomator | 跨应用 UI 测试 | 偶尔用于系统设置、通知栏等场景 |
你可以看到,组件之间是递进关系:Runner 负责运行,Core 提供基础能力,Rules 简化启动过程,Espresso 和 UI Automator 则帮你操控界面。嗯,这里要注意:不要一上来就全加,先评估你的测试类型。如果只做纯逻辑的单元测试(不需要设备),甚至可以用 Robolectric 模拟环境,但 Robolectric 不是 AndroidX Test 的一部分,我们后面章节会单独讲。
dependencies {
androidTestImplementation platform("androidx.test:test-bom:1.5.0")
androidTestImplementation "androidx.test:runner"
androidTestImplementation "androidx.test:core"
androidTestImplementation "androidx.test:rules"
androidTestImplementation "androidx.test.ext:junit"
androidTestImplementation "androidx.test.espresso:espresso-core"
}
1.4 整体结构图
我把上面讲的内容画成一张图,方便你直观理解各组件的关系与调用链路:
你看,Runner 像“调度中心”,它把 Core 和 Rules 提供的功能组合起来,再经过 Ext JUnit 的适配,最后通过 Espresso 或 UI Automator 完成具体操作。我在实际项目里,最常联合使用的是 ActivityScenarioRule + Espresso.onView(),写起来非常顺手。
1.5 快速上手示例
光说不练假把式,我们看一段最简单的 AndroidX Test 用例。我个人习惯把启动 Activity 抽成一个 Rule,测试方法里只关心交互逻辑:
@RunWith(AndroidJUnit4.class)
public class MainActivityTest {
@Rule
public ActivityScenarioRule<MainActivity> activityRule =
new ActivityScenarioRule<>(MainActivity.class);
@Test
public void testButtonClick() {
// 使用 Espresso 点击按钮
onView(withId(R.id.button_submit)).perform(click());
// 验证结果
onView(withId(R.id.text_result)).check(matches(withText("提交成功")));
}
}
这段代码会:先在设备上启动 MainActivity,然后点击 submit 按钮,检查结果文字。如果 button 或 textView 的 ID 写错了,测试会明确告诉你找不到视图——这就是为什么我喜欢用 AndroidX Test:失败信息清晰,定位问题秒级。