Android测试实战指南：JUnit、Espresso与Mockito框架详解

1. 项目概述：为什么Android测试是开发者的必修课？

干了这么多年Android开发，我见过太多项目在后期因为测试缺失而陷入泥潭。一个功能看似简单，上线后却因为一个边界条件没处理好，导致应用崩溃率飙升，团队不得不连夜加班打补丁。这种场景，相信不少同行都深有体会。Android测试，尤其是单元测试和UI测试，绝不是为了应付KPI或者满足代码覆盖率指标的“面子工程”，它本质上是一套保障应用质量、提升开发效率、降低维护成本的工程实践体系。

简单来说，Android测试可以分为两大类：单元测试和UI测试。单元测试关注的是代码中最小可测试单元（通常是一个函数或一个类）的逻辑正确性，它运行在本地JVM上，速度极快。而UI测试（或称集成测试、端到端测试）则模拟用户与应用的交互，验证整个界面流程是否符合预期，它需要运行在真实的设备或模拟器上。这两者相辅相成，构成了Android应用质量保障的基石。对于任何希望构建健壮、可维护应用的开发者或团队，掌握这两套框架的用法，是迈向专业开发的关键一步。

2. 核心测试框架生态全景解析

在深入具体操作之前，我们有必要对Android测试的“兵器库”有一个全局的认识。这能帮助你在面对具体问题时，快速选择最合适的工具。

2.1 单元测试框架：JUnit、Mockito与Robolectric的三叉戟

单元测试的核心是隔离与快速验证。在Android领域，我们主要依赖以下三个框架的组合：

1. JUnit 4/5：这是测试的骨架和运行器。它提供了@Test注解来标记测试方法，以及assertEquals、assertTrue等断言方法来验证结果。JUnit 4是目前Android项目的默认选择，而JUnit 5提供了更强大的参数化测试、动态测试等特性，但在Android项目中的集成需要额外配置。

2. Mockito / MockK：这是模拟（Mock）依赖的利器。在单元测试中，我们追求“隔离”，即只测试当前类（被测对象）的逻辑，其依赖的外部服务（如网络请求、数据库操作、系统服务Context）应该被“模拟”出来。Mockito（Java）和MockK（Kotlin）就是用来创建这些模拟对象，并预设它们行为的工具。例如，你可以模拟一个Repository，让它在被调用fetchData()方法时，直接返回一个预设好的测试数据，而不是真的去发起网络请求。

3. Robolectric：这是解决Android依赖问题的“桥梁”。纯JUnit测试无法调用Android SDK中的类（如TextView、Activity、SharedPreferences），因为它们需要Android运行环境。Robolectric通过实现一套“影子”（Shadow）类，在本地JVM上模拟了Android框架的行为，使得你可以在不启动模拟器的情况下，测试那些依赖Android环境的代码。它极大地加快了涉及Android组件的单元测试速度。

这三者的关系：通常，你会用JUnit组织测试，用Mockito/MockK来模拟非Android的依赖（如业务层接口），而对于必须使用Android SDK的类（如Context、Resources），则使用Robolectric来提供运行环境。当然，对于纯粹的、不涉及任何Android API的业务逻辑（如一个计算器类），只用JUnit就足够了。

2.2 UI测试框架：Espresso与UI Automator的分工协作

UI测试模拟用户操作，其核心框架是Espresso，而UI Automator则用于处理跨应用或系统级UI的测试。

1. Espresso：Google官方推荐的UI测试框架，专为单个应用内的UI测试而设计。它的API非常简洁，核心思想是“同步”。Espresso会等待主线程空闲后再执行下一个操作，这避免了因动画或网络加载导致的测试失败。它的核心API包括：

   • onView()：定位一个视图（View）。
   • perform()：在定位的视图上执行操作（如click(),typeText()）。
   • check()：断言视图的状态（如matches(isDisplayed()),withText()）。

2. UI Automator 2.0：当你的测试需要与系统UI交互（如下拉状态栏、点击系统对话框）或测试多个应用间的交互时，Espresso就力不从心了。UI Automator可以跨应用工作，它通过Android的辅助功能服务来识别和操作屏幕上的元素。它的API更偏向于基于控件属性（如resource-id,text）的查找。

选择策略：绝大多数应用内UI交互测试，应首选Espresso，因为它更快速、更稳定、API更友好。只有当你确实需要测试通知栏、权限弹窗、或应用跳转等场景时，才引入UI Automator。

3. 单元测试实战：从零搭建可测试的代码结构

理论说再多，不如动手写一行代码。我们从一个常见的场景开始：用户登录。假设我们有一个简单的登录功能，包含数据验证和网络请求。

3.1 设计可测试的架构：ViewModel + Repository模式

不可测试的代码往往是高度耦合的。例如，在Activity里直接写网络请求和逻辑判断。为了便于测试，我们采用MVVM模式进行解耦。

假设我们有以下分层结构：

• LoginViewModel：持有UI状态和业务逻辑，对外暴露LiveData或StateFlow。
• UserRepository：负责数据获取，可能来自网络（LoginRemoteDataSource）或本地数据库。
• LoginRemoteDataSource：使用Retrofit等库实际发起网络请求。

可测试性的关键：ViewModel通过构造函数依赖UserRepository（接口），而不是具体实现。这样，在测试时，我们可以轻松传入一个模拟的Repository。

// 1. 定义Repository接口 interface UserRepository { suspend fun login(username: String, password: String): Result<LoginResponse> } // 2. ViewModel依赖接口 class LoginViewModel(private val userRepository: UserRepository) : ViewModel() { private val _loginState = MutableStateFlow<LoginState>(LoginState.Idle) val loginState: StateFlow<LoginState> = _loginState fun onLoginClicked(username: String, password: String) { viewModelScope.launch { _loginState.value = LoginState.Loading val result = userRepository.login(username, password) _loginState.value = when (result) { is Result.Success -> LoginState.Success(result.data) is Result.Error -> LoginState.Error(result.exception.message) } } } }

3.2 编写纯逻辑单元测试（JUnit + Mockito）

首先，我们测试LoginViewModel的逻辑。它不直接依赖Android，所以我们可以只用JUnit和Mockito。

步骤1：添加依赖在你的模块的build.gradle.kts(或build.gradle) 文件中：

dependencies { // 单元测试依赖 testImplementation("junit:junit:4.13.2") testImplementation("org.mockito.kotlin:mockito-kotlin:5.2.1") // Kotlin版Mockito testImplementation("org.mockito:mockito-inline:5.2.0") // 用于模拟final类/方法（如Kotlin中的类） testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.8.0") // 协程测试支持 }

步骤2：编写测试类在src/test/java/...或src/test/kotlin/...目录下创建测试类。

import kotlinx.coroutines.ExperimentalCoroutinesApi import kotlinx.coroutines.test.StandardTestDispatcher import kotlinx.coroutines.test.runTest import org.junit.Assert.assertEquals import org.junit.Before import org.junit.Rule import org.junit.Test import org.mockito.Mock import org.mockito.junit.MockitoJUnit import org.mockito.junit.MockitoRule import org.mockito.kotlin.any import org.mockito.kotlin.whenever @OptIn(ExperimentalCoroutinesApi::class) class LoginViewModelTest { // 规则：初始化Mockito注解 @get:Rule val mockitoRule: MockitoRule = MockitoJUnit.rule() // 模拟依赖项 @Mock private lateinit var mockUserRepository: UserRepository // 使用TestDispatcher来控制协程，使测试可预测 private val testDispatcher = StandardTestDispatcher() private lateinit var viewModel: LoginViewModel @Before fun setup() { // 创建ViewModel，注入模拟的Repository viewModel = LoginViewModel(mockUserRepository) // 如果你在ViewModel中使用了Dispatchers.Main，需要替换为TestDispatcher // Dispatchers.setMain(testDispatcher) // 通常需要额外的设置 } @Test fun `login with valid credentials should emit success state`() = runTest(testDispatcher) { // Given: 准备测试数据并设置模拟行为 val testUsername = "test@email.com" val testPassword = "password123" val expectedResponse = LoginResponse(userId = "123", token = "abc") whenever(mockUserRepository.login(any(), any())).thenReturn(Result.Success(expectedResponse)) // 收集StateFlow的值以进行断言 val collectedStates = mutableListOf<LoginState>() val job = viewModel.loginState .onEach { collectedStates.add(it) } .launchIn(this) // When: 执行被测方法 viewModel.onLoginClicked(testUsername, testPassword) // Then: 验证状态流转符合预期 assertEquals(3, collectedStates.size) assertEquals(LoginState.Idle, collectedStates[0]) // 初始状态 assertEquals(LoginState.Loading, collectedStates[1]) // 加载状态 val successState = collectedStates[2] as LoginState.Success assertEquals(expectedResponse, successState.data) job.cancel() } @Test fun `login with network error should emit error state`() = runTest(testDispatcher) { // Given val expectedException = IOException("Network error") whenever(mockUserRepository.login(any(), any())).thenReturn(Result.Error(expectedException)) val collectedStates = mutableListOf<LoginState>() val job = viewModel.loginState .onEach { collectedStates.add(it) } .launchIn(this) // When viewModel.onLoginClicked("user", "pass") // Then assertEquals(LoginState.Loading, collectedStates[1]) val errorState = collectedStates[2] as LoginState.Error assertEquals("Network error", errorState.message) job.cancel() } }

实操心得：测试StateFlow或LiveData时，关键在于收集其发射的值并进行断言。使用runTest和TestDispatcher可以确保协程在测试中同步执行，避免异步带来的不确定性。Mockito的whenever（Kotlin）或when（Java）是用来定义模拟对象行为的核心方法。

3.3 编写涉及Android组件的单元测试（JUnit + Robolectric）

现在，假设我们有一个EmailValidator工具类，它用到了android.util.Patterns.EMAIL_ADDRESS这个Android SDK中的正则表达式。

步骤1：添加Robolectric依赖

dependencies { testImplementation("org.robolectric:robolectric:4.12.1") testImplementation("androidx.test.ext:junit:1.1.5") // AndroidX Test扩展，提供AndroidJUnit4运行器等 }

步骤2：配置测试运行环境在测试类上使用@RunWith注解指定Robolectric测试运行器，并通过@Config配置SDK版本等。

import android.util.Patterns import org.junit.Assert.assertFalse import org.junit.Assert.assertTrue import org.junit.Test import org.junit.runner.RunWith import org.robolectric.RobolectricTestRunner import org.robolectric.annotation.Config @RunWith(RobolectricTestRunner::class) // 使用Robolectric运行器 @Config(sdk = [Config.TARGET_SDK]) // 指定SDK版本，使用目标SDK class EmailValidatorTest { @Test fun `valid email format should return true`() { // 这里可以直接使用Android的Patterns，因为Robolectric提供了实现 val isValid = Patterns.EMAIL_ADDRESS.matcher("test@example.com").matches() assertTrue(isValid) } @Test fun `invalid email format should return false`() { val isValid = Patterns.EMAIL_ADDRESS.matcher("invalid-email").matches() assertFalse(isValid) } // 测试你自己的工具函数 @Test fun `isValidEmail with correct format returns true`() { assertTrue(EmailValidator.isValidEmail("name@email.com")) } }

注意事项：Robolectric测试比纯JUnit测试慢，因为它需要加载Android框架的“影子”类。应将其用于确实需要Android环境的测试，对于纯业务逻辑，尽量使用纯JUnit测试以保持测试套件的速度。

4. UI测试实战：用Espresso模拟用户旅程

UI测试的目标是确保界面元素能正确响应用户操作。我们以测试一个简单的登录界面为例。

4.1 环境搭建与基础配置

步骤1：添加Espresso依赖

dependencies { androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1") androidTestImplementation("androidx.test:runner:1.5.2") androidTestImplementation("androidx.test:rules:1.5.2") androidTestImplementation("androidx.test.ext:junit:1.1.5") // 包含AndroidJUnit4 // 如果需要测试RecyclerView androidTestImplementation("androidx.test.espresso:espresso-contrib:3.5.1") }

步骤2：创建测试类并配置测试运行器在src/androidTest/目录下创建测试类。UI测试需要运行在设备或模拟器上，因此属于插桩测试（Instrumentation Test）。

import androidx.test.core.app.ActivityScenario import androidx.test.espresso.Espresso.onView import androidx.test.espresso.action.ViewActions.* import androidx.test.espresso.assertion.ViewAssertions.matches import androidx.test.espresso.matcher.ViewMatchers.* import androidx.test.ext.junit.runners.AndroidJUnit4 import org.junit.After import org.junit.Before import org.junit.Test import org.junit.runner.RunWith @RunWith(AndroidJUnit4::class) // 使用AndroidJUnit4运行器 class LoginActivityTest { private lateinit var activityScenario: ActivityScenario<LoginActivity> @Before fun setUp() { // 在每条测试开始前启动Activity activityScenario = ActivityScenario.launch(LoginActivity::class.java) } @After fun tearDown() { // 在每条测试结束后关闭Activity activityScenario.close() } }

4.2 编写核心UI交互测试用例

假设登录界面有两个EditText（id分别为R.id.et_username和R.id.et_password）和一个Button（id为R.id.btn_login），以及一个显示错误信息的TextView（id为R.id.tv_error）。

@Test fun `login with empty username shows error`() { // 1. 在密码输入框输入内容（确保焦点转移，触发用户名验证） onView(withId(R.id.et_password)).perform(typeText("somePassword"), closeSoftKeyboard()) // 2. 直接点击登录按钮 onView(withId(R.id.btn_login)).perform(click()) // 3. 断言错误提示文本是否显示且内容正确 onView(withId(R.id.tv_error)) .check(matches(isDisplayed())) // 检查是否可见 .check(matches(withText(R.string.error_username_empty))) // 检查文本内容 } @Test fun `login with valid credentials navigates to home screen`() { // 0. 假设我们有一个模拟网络成功的Hilt测试模块或使用MockWebServer // 这里假设界面逻辑正确时会跳转到HomeActivity // 1. 输入正确的用户名和密码 onView(withId(R.id.et_username)).perform(typeText("test@email.com"), closeSoftKeyboard()) onView(withId(R.id.et_password)).perform(typeText("correctPassword"), closeSoftKeyboard()) // 2. 点击登录按钮 onView(withId(R.id.btn_login)).perform(click()) // 3. 验证是否跳转到了HomeActivity // 可以通过检查当前Activity的组件名，或者检查HomeActivity特有的UI元素 intended(hasComponent(HomeActivity::class.java.name)) // 需要espresso-intents库 // 或者更简单：检查HomeActivity的标题是否出现 onView(withText(R.string.home_title)).check(matches(isDisplayed())) } @Test fun `login button is disabled when password is less than 6 characters`() { // 1. 输入用户名 onView(withId(R.id.et_username)).perform(typeText("test@email.com"), closeSoftKeyboard()) // 2. 输入一个过短的密码 onView(withId(R.id.et_password)).perform(typeText("123"), closeSoftKeyboard()) // 3. 断言登录按钮处于不可用状态（disabled） onView(withId(R.id.btn_login)).check(matches(not(isEnabled()))) // 4. 继续输入密码达到6位 onView(withId(R.id.et_password)).perform(typeText("456"), closeSoftKeyboard()) // 现在密码是"123456" // 5. 断言登录按钮变为可用状态 onView(withId(R.id.btn_login)).check(matches(isEnabled())) }

实操心得：closeSoftKeyboard()操作非常重要。软键盘的弹出和收起是异步的，可能会遮挡按钮或影响click()操作的执行。在执行完typeText()后习惯性地关闭软键盘，能提高测试的稳定性。另外，对于按钮状态的测试，反映了对UI逻辑的细致验证，这能有效防止前端验证逻辑的漏洞。

4.3 测试列表（RecyclerView）和异步操作

测试RecyclerView是UI测试中的一个常见难点。Espresso提供了RecyclerViewActions来帮助操作列表项。

import androidx.test.espresso.contrib.RecyclerViewActions @Test fun `click on first item in list opens detail screen`() { // 假设MainActivity展示一个RecyclerView (id: R.id.recycler_view) // 1. 滚动到指定位置（这里是第0项） onView(withId(R.id.recycler_view)) .perform(RecyclerViewActions.actionOnItemAtPosition<RecyclerView.ViewHolder>(0, click())) // 2. 验证是否跳转到详情页 onView(withId(R.id.tv_detail_title)).check(matches(isDisplayed())) } @Test fun `scroll to item with specific text and click`() { // 如果需要根据内容来查找并操作项目 onView(withId(R.id.recycler_view)) .perform(RecyclerViewActions.scrollTo<RecyclerView.ViewHolder>( hasDescendant(withText("特定项目文本")) )) .perform(RecyclerViewActions.actionOnItem<RecyclerView.ViewHolder>( hasDescendant(withText("特定项目文本")), click() )) }

处理异步加载（如网络请求）：Espresso内置了同步机制，但有时需要显式等待。可以使用IdlingResource，但更现代的作法是利用EspressoIdlingResource库（现已整合到androidx.test.espresso.idling）或在ViewModel/Repository层暴露可观察的“空闲”状态。对于使用协程的现代应用，确保UI测试在Dispatchers.Main上执行，Espresso通常能很好地处理。

5. 测试策略、常见问题与效能提升

写测试不难，写好、维护好一个高效的测试套件却很有挑战。下面分享一些实战中积累的策略和避坑指南。

5.1 单元测试与UI测试的平衡策略

不要试图用UI测试覆盖所有场景。记住一个原则：测试金字塔。

• 底层（大量）：单元测试。快速、稳定、成本低。应覆盖所有核心业务逻辑、工具类、ViewModel的State转换等。目标是高覆盖率（通常>70%）。
• 中层（适量）：集成测试。测试模块间的交互，例如Repository与DataSource的集成，或ViewModel与Android组件（使用Robolectric）的集成。
• 顶层（少量）：UI测试（端到端测试）。缓慢、脆弱、成本高。只用于验证关键的用户旅程（Happy Path），例如“新用户注册登录并完成核心操作”。每个主要用户流有1-2个核心UI测试即可。

一个常见的反模式：用UI测试去验证一个输入框的文本格式校验。这应该由单元测试来完成。UI测试只关心“当输入错误格式时，错误提示是否显示了出来”。

5.2 常见问题排查与调试技巧

1. NoMatchingViewException(找不到视图)：

   • 原因：视图ID不对、视图不可见（visibility不是VISIBLE）、视图还没加载出来（异步）。
   • 排查：
     • 使用onView(isRoot()).perform(ViewActions.dump())打印当前视图层次结构，检查目标视图是否存在及其状态。
     • 确保在perform(click())等操作前，视图是isDisplayed()和isEnabled()的。
     • 对于异步加载，考虑使用Espresso.onIdle()等待，或更优地，使用IdlingResource同步你的后台任务。

2. PerformException(操作执行失败)：

   • 原因：视图不可操作，例如尝试click()一个android:clickable="false"的视图，或者在软键盘遮挡时点击输入框。
   • 解决：检查视图属性。在输入文本前或后执行closeSoftKeyboard()。

3. 测试在CI（持续集成）上失败，本地却通过：

   • 原因：CI机器性能差导致动画或加载更慢，时间差问题。
   • 解决：
     • 在测试代码或build.gradle中禁用动画：adb shell settings put global window_animation_scale 0 && adb shell settings put global transition_animation_scale 0 && adb shell settings put global animator_duration_scale 0。
     • 避免使用sleep()，改用Espresso的IdlingResource或更智能的等待条件。
     • 确保测试环境干净，每次测试前清理应用数据：在@Before中使用TestRule如ActivityScenarioRule并配合clearApplicationData()规则。

4. Robolectric测试报错Resources$NotFoundException：

   • 原因：Robolectric没有正确加载你的应用资源。
   • 解决：确保测试类使用了@RunWith(RobolectricTestRunner::class)，并且@Config中指定了正确的application（如果你的自定义Application类很重要）。有时需要创建专门的测试Application类。

5.3 提升测试效能与可维护性

1. 使用测试规则（Test Rules）：ActivityScenarioRule或ActivityTestRule可以简化Activity生命周期的管理，避免在@Before和@After中手动处理。

   @get:Rule val activityRule = activityScenarioRule<LoginActivity>() // 然后在测试中直接使用 activityRule.scenario

2. 页面对象（Page Object）模式：将页面的定位和操作封装成类。这极大提升了测试代码的可读性和可维护性。

   class LoginPage { fun enterUsername(username: String) = onView(withId(R.id.et_username)).perform(typeText(username)) fun enterPassword(password: String) = onView(withId(R.id.et_password)).perform(typeText(password)) fun clickLogin() = onView(withId(R.id.btn_login)).perform(click()) fun checkErrorDisplayed(errorText: String) = onView(withId(R.id.tv_error)).check(matches(withText(errorText))) } // 在测试中使用 @Test fun testLogin() { LoginPage().apply { enterUsername("user") enterPassword("pass") clickLogin() checkErrorDisplayed("Invalid credentials") } }

3. 模拟网络层：UI测试不应依赖真实网络。使用MockWebServer（OkHttp）或MockK/Mockito配合依赖注入（如Hilt）来模拟网络响应。这保证了测试的确定性和速度。

   // 在@Before中启动MockWebServer并注入到你的网络客户端 val mockWebServer = MockWebServer() @Before fun setup() { mockWebServer.start() val baseUrl = mockWebServer.url("/").toString() // 将baseUrl注入到你的Retrofit实例中 } @Test fun testLoginSuccess() { // 为特定请求路径设置模拟响应 mockWebServer.enqueue(MockResponse().setBody("{ \"token\": \"fake_token\" }")) // ... 执行UI操作 // 验证请求是否按预期发出 val request = mockWebServer.takeRequest() assertEquals("/login", request.path) }

4. 定期清理与重构测试：随着功能迭代，测试代码也会腐化。定期检查哪些测试经常失败（脆弱测试），并重构它们。删除不再需要的测试，合并重复的测试逻辑。

编写测试是一个需要持续投入和精进的技能。初期可能会觉得繁琐，但当你看到它成功拦截了一个潜在的线上bug，或者在重构代码时给你带来的巨大信心时，你会觉得所有投入都是值得的。从今天开始，为你新增的每一个重要功能，都配套写上单元测试和必要的UI测试吧。