安卓单元测试面试必问，3个方案对比让你选型不踩坑

刚入行写安卓，是不是觉得会点Kotlin或Java就能接活了？结果一上手真实项目，代码堆成一团，改个按钮颜色可能弄崩支付流程，心里发虚。更扎心的是，面试官一开口问“你项目里怎么保证质量”，你愣住，只能支支吾吾说靠手测。这场景太熟悉了，学会语法却不知怎么搭项目，这是大多数应届生的通病。

单元测试就是破局关键。它不是高大上的理论，而是面试必问的实操技能，更是你从“写代码的”变成“工程师”的分水岭。今天不聊虚的，直接上干货，对比三种主流安卓单元测试方案：Robolectric、Espresso、AndroidJUnitRunner。它们各有所长，选错了不仅效率低，还可能被面试官看轻。咱们用代码说话，把坑都填平。

三种方案定位：谁在干什么活

先搞清楚每个工具是干嘛的，别一上来就混用。

Robolectric 是本地跑单测的利器。它模拟Android环境，在JVM上执行，不用真机或模拟器。速度极快，一个测试用例毫秒级完成。适合测试纯业务逻辑、ViewModel、Repository这类不依赖UI的类。它的本质是“模拟”，把Android框架的API映射到JVM可执行的代码上。

Espresso 是UI自动化测试的王者。它操作的是真实UI树，模拟用户点击、滑动、输入。必须跑在模拟器或真机上，速度慢但真实度高。适合验证用户交互流程，比如登录页填错密码该不该弹提示。它和UI线程同步，能精准定位控件，是UI测试的事实标准。

AndroidJUnitRunner 是集成测试的底座。它继承自JUnit，但专为Android设计，能访问Context、SharedPreferences、数据库等Android资源。测试代码跑在设备上，速度介于前两者之间。适合测试涉及Android组件（Activity、Service）或系统API的场景，比如验证某个Service启动后是否正确写入日志。

一句话总结：Robolectric快但假，Espresso真但慢，AndroidJUnitRunner中间地带。三者不是替代关系，而是互补。成熟项目里三者共存，各司其职。

核心差异对比：一张表看懂怎么选

光说不练假把式，直接上对比表。这张表是我带实习生时反复强调的，面试前背下来，回答时信手拈来。

维度	Robolectric	Espresso	AndroidJUnitRunner
执行环境	JVM本地	设备/模拟器	设备/模拟器
测试速度	极快（毫秒级）	慢（秒级）	中等（百毫秒级）
依赖UI	否	是	可选
依赖Android API	模拟	真实	真实
调试难度	低，IDE直接断点	中，需设备日志	中，需设备日志
典型场景	业务逻辑、ViewModel	用户交互、UI状态	组件通信、系统API
学习曲线	平缓	陡峭	中等
维护成本	低	高（UI变更易崩）	中

注意看“维护成本”这一行。Espresso测试脚本对UI布局敏感，改个ID可能全崩，这是真实项目里的痛点。Robolectric因为不依赖UI，脚本稳定性最高。面试时如果问到“为什么不用Espresso测所有东西”，这就是你的得分点：UI测试成本高，该用快测就用快测。

代码写法对比：同一功能三种实现

假设我们要测试一个“用户登录成功后跳转到主页”的功能。下面三段代码分别用三种方案实现，语言均为Kotlin，配置要求见注释。

方案一：Robolectric 测试 ViewModel 逻辑

@RunWith(RobolectricTestRunner::class)
@Config(sdk = [33]) // 指定模拟的Android版本
class LoginViewModelTest {@Testfun `login success should emit main route`() {// Given: 模拟Repository返回成功val mockRepository = mockk<AuthRepository>()every { mockRepository.login(any(), any()) } returns Result.success(User("123", "Tom"))val viewModel = LoginViewModel(mockRepository)val capturedRoute = mutableListOf<String>()// When: 执行登录viewModel.login("user@example.com", "pass123")viewModel.route.collect { capturedRoute.add(it) }// Then: 验证跳转路由assertContentEquals(listOf("MAIN"), capturedRoute)}
}

关键点：@Config(sdk = [33]) 必须显式指定，否则Robolectric可能用默认版本导致API不匹配。mockk 是Kotlin协程友好的Mock库，比Mockito更适合Kotlin项目。测试跑在JVM，断点调试丝滑。

方案二：Espresso 测试 UI 交互

@RunWith(AndroidJUnit4::class)
class LoginActivityUITest {@Testfun `valid credentials should navigate to main`() {// Given: 打开登录页activityScenario.launch()// When: 输入凭证并点击onView(withId(R.id.editTextEmail)).perform(typeText("user@example.com"))onView(withId(R.id.editTextPassword)).perform(typeText("pass123"))onView(withId(R.id.buttonLogin)).perform(click())// Then: 验证主页控件可见onView(withId(R.id.textViewWelcome)).check(matches(isDisplayed()))}
}

关键点：activityScenario 是新版AndroidX推荐写法，比ActivityScenarioRule更简洁。onView(withId()) 依赖布局ID，ID一改测试就崩，所以UI测试要配合稳定ID命名规范。必须在模拟器或真机跑，CI环境要配置AVD。

方案三：AndroidJUnitRunner 测试 Service 通信

@RunWith(AndroidJUnitRunner::class)
class LoginServiceTest {@Testfun `login service should write user to shared prefs`() {// Given: 启动Serviceval serviceIntent = Intent(context, LoginService::class.java)context.startService(serviceIntent)// When: 等待服务执行（简化处理，实际需同步机制）Thread.sleep(100)// Then: 验证SharedPreferencesval prefs = context.getSharedPreferences("user_prefs", Context.MODE_PRIVATE)assertEquals("user@example.com", prefs.getString("email", null))}
}

关键点：context 来自@TestContext注入，或手动获取。Thread.sleep() 是反模式，真实项目要用CountDownLatch或LiveData观察。此方案验证的是Android组件行为，不是业务逻辑，所以断言针对系统资源。

适用场景与避坑指南

选对方案是一回事，用好是另一回事。以下是实战中踩过的坑，应届生尤其要注意。

Robolectric 的坑：

不支持所有Android API。比如NfcAdapter、Camera这类硬件相关API模拟不全，测不了就换方案。
版本对齐很重要。@Config(sdk = [33]) 要和你项目的compileSdkVersion一致，否则会出现方法找不到的诡异错误。
依赖管理：Robolectric本身依赖庞大，Gradle配置里要加testImplementation，别用implementation。

Espresso 的坑：

动画干扰。登录页有入场动画，click()时控件还没稳定，测试随机失败。解决方案：waitUntil(1000) { onView(...).check(matches(isDisplayed())) } 或关闭动画。
多窗口/多Activity。测试登录跳转时，登录页还没销毁，主页已创建，onView可能找不到目标。用onAllViews()或指定withParent限定范围。
CI环境慢。模拟器启动要30秒以上，一个UI测试跑10秒。建议UI测试单独跑，CI流水线里用@Category(UITest::class)标记，日常构建跳过。

AndroidJUnitRunner 的坑：

异步地狱。Service、BroadcastReceiver都是异步的，Thread.sleep()是定时炸弹。用CountDownLatch、Handler.postDelayed或LiveData观察等待。
资源污染。一个测试写了SharedPreferences，下一个测试读到脏数据。每个测试类加@Before清理资源，或用Robolectric的Shadow重置。
Context获取。别硬编码context，用InstrumentationRegistry.getInstrumentation().targetContext或注入。

通用避坑：

测试命名：用“场景_条件_期望”格式，比如login_with_invalid_password_should_show_error。面试时展示命名规范，显得专业。
覆盖率不是目标。80%覆盖率但全是assertEquals(1, 1)毫无意义。关注核心业务逻辑的分支覆盖。
持续集成。单元测试必须进CI。每次提交自动跑，红了就挡。没CI的测试是摆设。