Android 测试全景:从 JVM 到真机

那条核心张力:JVM ↔ 真机

第 5 章已经点过两个 sourceSet,这里把它当作理解整个栈的坐标轴:

金字塔(第 4 章)在 Android 上的落地就是:尽可能把测试往 test/ 挪(快),只有真的需要框架/UI 的,才放 androidTest/(慢)。

Robolectric:把 Android 搬进 JVM

但有大量代码卡在中间:它需要一点 Android 框架(比如 Context、SharedPreferences、资源),但又没必要为它启动整个模拟器。Robolectric 就是为这个缝生的:

一张栈图:每个工具站在哪

把 Android 测试常用工具,按"范围/速度"从快到慢排一遍,你就有了完整地图:

注意大部分工具都在 JVM 那侧 —— 这是好事。你能把绝大多数验证放在快的一侧,只把真正需要真机的 UI 旅程留给慢的一侧。

Hilt:让测试能换掉依赖

要想 fake 掉依赖(第 10 章),前提是能注入。用了 Hilt 的项目,测试里可以整体替换某个模块:

@HiltAndroidTest
class LoginTest {
    @get:Rule val hilt = HiltAndroidRule(this)

    @BindValue @JvmField                       // 用 fake 替换真的 UserRepo
    val userRepo: UserRepo = FakeUserRepo()

    @Test fun `登录`() { /* 注入的是 fake,不碰真网络 */ }
}

@BindValue 让你在测试里把某个真依赖换成 fake/mock,而应用其余部分的接线保持不变。这是"在架构边界上替身"(第 11 章)在 Android 上的标准做法。

两个必备的 Rule

有两个 JUnit Rule,几乎每个 Android 测试项目都会封装:

// 1) 替换 Dispatchers.Main —— 纯 JVM 测试里没有真的主线程(第 12 章)
class MainDispatcherRule : TestWatcher() {
    private val dispatcher = StandardTestDispatcher()
    override fun starting(d: Description) { Dispatchers.setMain(dispatcher) }
    override fun finished(d: Description) { Dispatchers.resetMain() }
}

// 2) Compose 测试规则
@get:Rule val compose = createComposeRule()   // 或 createAndroidComposeRule<T>()

第一个解决"JVM 里没有主线程调度器"的问题;没有它,任何用了 viewModelScope(它跑在 Main 上)的 ViewModel 测试都会崩。第二个给你 compose.onNodeWith... 那套 API。把它们封成可复用的 Rule,是每个 Android 测试基建的第一块砖。

该往哪层投精力

AI 与 Android 测试栈

配置一眼:测试依赖分两组

Android 的测试依赖,在 build.gradle.kts 里也分成对应的两组,别放错:

dependencies {
    // testImplementation:JVM 单元测试(src/test/)
    testImplementation("org.jetbrains.kotlin:kotlin-test")
    testImplementation("io.mockk:mockk:...")
    testImplementation("app.cash.turbine:turbine:...")
    testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:...")
    testImplementation("org.robolectric:robolectric:...")   // 想在 JVM 上碰框架

    // androidTestImplementation:真机测试(src/androidTest/)
    androidTestImplementation("androidx.test.ext:junit:...")
    androidTestImplementation("androidx.compose.ui:ui-test-junit4:...")
    androidTestImplementation("androidx.test.espresso:espresso-core:...")
}

一个常见的困惑:MockK 有个专门的 mockk-android artifact,给 androidTest 用;而纯 JVM 测试用普通的 mockk。放错分组会出现「本地能跑、CI 上找不到类」这类怪事。

Robolectric 一眼:JVM 上跑「像真机」的测试

看它长什么样,你就懂了它站在栈的哪个位置 —— 写起来像真机测试(有 Context、能 launch Activity),却跑在 test/ 的 JVM 上:

@RunWith(AndroidJUnit4::class)   // 在 test/ 里,这会触发 Robolectric
class SharedPrefsRepoTest {
    private val context = ApplicationProvider.getApplicationContext<Context>()

    @Test fun `存了 token 能读回来`() {
        val repo = SharedPrefsRepo(context)   // 用了真的 SharedPreferences API
        repo.saveToken("abc")
        assertEquals("abc", repo.token())     // Robolectric 提供了 shadow 实现
    }
}

这段代码碰了 Context 和 SharedPreferences(真机才有的东西),但因为 Robolectric 在 JVM 上给了它们一套 shadow 实现,它不用装 APK、不用连模拟器,几百毫秒跑完。这正是「我需要一点框架,但不想为它上真机」那个中间层的答案。

Android 讲完了。下一章把同一套思想在前端过一遍 —— 你会发现形状一模一样,只是换了工具:Vitest 是单元、Testing Library 是"像用户一样查询"的组件测试、Playwright 是端到端。而 Testing Library 的那句口头禅,恰好是这整本书哲学的一句话总结。