1. 为什么我劝你把单元测试当回事
刚入行那会儿，我对单元测试的态度就俩字：嫌弃。觉得写测试是浪费时间，业务代码都写不完，哪有功夫伺候测试用例。直到有一次改了一个看似无害的工具类方法，上线后引发连锁崩溃，排查了整整两天才发现是某个边界条件没覆盖到。从那以后我才老老实实开始写测试，一路踩坑到现在，算是把 Android 单元测试这套东西摸了个七七八八。
这篇内容聊的就是Android 单元测试这件事本身——它是什么、能解决什么问题、该怎么落地。简单说，单元测试就是针对代码中最小可测单元（通常是一个方法或一个类）编写的自动化验证代码，跑一遍几秒钟，告诉你“你刚改的东西有没有把原来的逻辑搞坏”。它解决的核心痛点是：回归验证成本高、重构没底气、联调前 bug 发现太晚。适合谁看？刚接触 Android 开发想建立工程习惯的新人、写了测试但总是跑不起来的中级开发、以及想给老项目补测试但不知道从哪下手的朋友。下面我按“整体思路—核心细节—实操落地—问题排查”这条线，把这件事从头到尾讲透。
2. 整体设计与思路拆解
2.1 先搞清楚测试金字塔，别一上来就写 UI 测试
很多人对单元测试的第一个误解，是把它和“自动化测试”划等号，然后一头扎进 Espresso 或者 UI 自动化里，结果用例跑得慢、维护成本高、动不动就 flaky（时好时坏）。正确的姿势是先理解测试金字塔：底层是大量的单元测试（JVM 上跑，毫秒级），中间是集成测试（验证模块间协作），顶层是少量的UI 测试（真机/模拟器上跑，秒级甚至分钟级）。
为什么这么分层？因为越往上层，执行越慢、越不稳定、定位问题越难。一个单元测试挂了，你基本能立刻知道是哪个方法出了问题；一个 UI 测试挂了，可能是网络、可能是动画时序、可能是设备性能，排查成本天差地别。所以我的原则很明确：能用单元测试覆盖的逻辑，绝不往上推。业务里的金额计算、日期格式化、状态机流转、数据转换，这些纯逻辑统统应该在 JVM 层解决掉。
2.2 本地测试和仪器测试，边界要划清楚
Android 的测试从运行环境上分两类：本地单元测试（src/test/，跑在本地 JVM 上）和仪器测试（src/androidTest/，跑在真机或模拟器上）。这个目录划分不是随便定的，它直接决定了你的测试能不能快速反馈。
本地测试的优势是快——没有设备启动开销，没有真机资源竞争，CI 上并行跑几百个用例也就几十秒。代价是它拿不到真实的 Android 框架实现，比如Log、SharedPreferences、Context这些在纯 JVM 上是没有的。怎么办？两条路：一是把依赖 Android 框架的逻辑抽离出去（这是首选，架构上就该这么干），二是用 Mock 框架或者 Robolectric 这类工具模拟框架行为。
仪器测试则相反，它能拿到真实的Context、真实的资源、真实的数据库，但慢且依赖设备。我的经验是：仪器测试只留给那些真正需要 Android 运行时才能验证的东西，比如数据库迁移、ContentProvider 交互、自定义 View 的测量布局。其余一律下沉到本地测试。
2.3 测试框架选型：JUnit 打底，Mock 框架补位
框架这块没什么好纠结的，主流组合就那几样。JUnit 4是绝对的基础，@Test、@Before、@After、@RunWith这些注解你绕不开；JUnit 5 在 Android 生态里支持度还在爬坡，新项目可以试，老项目别折腾。Mockito用来造替身对象，验证交互行为；MockK是 Kotlin 项目的好选择，对协程、扩展函数、object 单例的支持比 Mockito 顺手得多。断言库方面，Google 的Truth比 JUnit 自带的assertEquals可读性强不少，assertThat(x).isEqualTo(y)这种链式写法出错信息也更友好。
选型的逻辑很简单：跟着项目语言和团队习惯走。纯 Java 项目用 JUnit4 + Mockito + Truth 是最稳的组合，资料多、坑少；Kotlin 为主的项目直接上 MockK，省去一堆mockito-kotlin的适配烦恼。别为了追新去堆一堆冷门框架，测试代码也是要长期维护的资产。
2.4 可测试性设计：测试写不动，往往是代码结构的问题
这一点是我踩坑最多的地方。早期我总抱怨“这代码没法测”，后来才明白：测试写不出来，八成是代码本身耦合太重。一个方法里既做网络请求、又做数据解析、还顺手弹了个 Toast，你让测试怎么下手？
所以写测试之前，先做一轮“可测试性改造”。核心手段就几个：依赖注入（把外部依赖通过构造函数或参数传进来，而不是在方法里 new）、单一职责（一个类只干一件事）、面向接口编程（依赖抽象而非具体实现，方便替换成 Mock）。举个最典型的例子：一个UserRepository如果内部直接new Retrofit()，你根本没法在测试里控制网络返回；改成构造函数注入ApiService接口，测试时传个 Mock 进去，想返回什么数据就返回什么数据。这个改造过程本身就是在提升代码质量，一举两得。
3. 核心细节解析与实操要点
3.1 依赖配置：别小看 build.gradle 里这几行
工欲善其事，先把依赖配好。本地单元测试需要的依赖通常包括 JUnit、Mock 框架、断言库，如果涉及协程还要加kotlinx-coroutines-test。下面是一个 Kotlin 项目的典型配置，我按用途分了组，方便你按需取舍：
dependencies { // 基础测试框架 testImplementation "junit:junit:4.13.2" // Mock 框架（Kotlin 项目首选 MockK） testImplementation "io.mockk:mockk:1.13.8" // 断言库 testImplementation "com.google.truth:truth:1.1.5" // 协程测试支持 testImplementation "org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3" // 需要模拟 Android 框架时用 Robolectric testImplementation "org.robolectric:robolectric:4.11.1" // 仪器测试相关 androidTestImplementation "androidx.test.ext:junit:1.1.5" androidTestImplementation "androidx.test.espresso:espresso-core:3.5.1" }这里有个细节值得说：testImplementation和androidTestImplementation是两个不同的配置，前者只对src/test/生效，后者只对src/androidTest/生效。我见过有人把 MockK 配到androidTestImplementation里，然后在本地测试里死活 import 不到，排查半天。另外，Robolectric 的版本要和你的compileSdk大致匹配，版本差太多容易出现资源加载异常。
注意：依赖版本不要盲目追最新，尤其是 MockK 和 Robolectric，大版本升级经常有 API 变动。团队里最好统一版本号，写进版本管理文件里，避免各人本地环境不一致导致“我这儿能跑你那儿不行”。
3.2 测试用例的三段式结构：Arrange-Act-Assert
写测试用例有个经典范式叫AAA 模式，即 Arrange（准备）、Act（执行）、Assert（断言）。听起来像八股，但真按这个结构写，用例的可读性会好很多。看个例子，假设有个计算折扣的工具类：
class DiscountCalculatorTest { @Test fun `满减规则_订单满100减20_应返回80`() { // Arrange：准备被测对象和输入 val calculator = DiscountCalculator() val orderAmount = 100.0 // Act：执行被测方法 val result = calculator.calculate(orderAmount) // Assert：验证结果 assertThat(result).isEqualTo(80.0) } }三段之间用空行隔开，一眼就能看出哪部分是准备、哪部分是验证。Kotlin 里可以用反引号给方法起中文名，可读性直接拉满，但注意反引号方法名在部分旧版工具链上可能有兼容问题，Java 项目就用should_xxx_when_yyy这种下划线命名法。
3.3 Mock 的正确姿势：只 Mock 边界，别 Mock 一切
Mock 框架很强大，但滥用起来危害不小。我见过有人把被测类内部的所有依赖全 Mock 掉，连一个简单的数据类都不放过，结果测试跑通了，但实际集成时照样崩——因为 Mock 出来的行为和真实实现不一致。
我的原则是：只 Mock 跨越边界的依赖，比如网络接口、数据库访问、系统时间、随机数生成器。被测类内部的纯逻辑、数据类、工具方法，一律用真实实现。这样测试才有意义，它验证的是真实逻辑，而不是你臆想出来的 Mock 行为。
再补充一个 MockK 的实用技巧：验证方法调用次数用verify(exactly = 1) { ... }，验证参数用verify { repository.save(match { it.id == 1 }) }。协程场景下记得用coEvery/coVerify而不是every/verify，否则挂起函数会报错。这个坑我踩过不止一次，报错信息还特别隐晦。
3.4 测试命名与组织：让失败信息自己说话
测试挂了的时候，你希望第一眼看到什么？是test1 failed，还是订单金额为负数时_应抛出IllegalArgumentException？答案不言而喻。命名规范这块，我推荐“被测场景 + 预期行为”的组合，中文英文都行，关键是描述清楚。
组织上，一个被测类对应一个测试类，测试类里按方法分组。JUnit 4 没有原生的嵌套分组，可以用@RunWith(Enclosed.class)做内部类分组，但用起来略繁琐；更简单的做法是用注释分隔区块，或者干脆一个方法一个测试类（方法特别复杂时）。测试代码也是代码，可读性同样重要，别写得比业务代码还乱。
4. 实操过程与核心环节实现
4.1 从零写第一个可运行的单元测试
光说不练假把式，走一遍完整流程。假设我们有个PriceFormatter类，负责把分单位的整数价格格式化成“¥xx.xx”的字符串：
class PriceFormatter { fun format(priceInCents: Long): String { require(priceInCents >= 0) { "价格不能为负数" } val yuan = priceInCents / 100 val cents = priceInCents % 100 return "¥$yuan.${cents.toString().padStart(2, '0')}" } }第一步，在src/test/java/下对应的包路径里新建测试类。第二步，写用例覆盖正常值、边界值、异常值三类情况：
class PriceFormatterTest { private lateinit var formatter: PriceFormatter @Before fun setUp() { formatter = PriceFormatter() } @Test fun `正常价格_1999分_格式化为19点99元`() { assertThat(formatter.format(1999)).isEqualTo("¥19.99") } @Test fun `边界价格_0分_格式化为0点00元`() { assertThat(formatter.format(0)).isEqualTo("¥0.00") } @Test fun `个位分_5分_补零为0点05元`() { assertThat(formatter.format(5)).isEqualTo("¥0.05") } @Test(expected = IllegalArgumentException::class) fun `负数价格_应抛出异常`() { formatter.format(-1) } }第三步，右键运行或者命令行./gradlew testDebugUnitTest。跑通之后你会看到绿色的通过标记，改坏业务代码再跑一次，红色失败信息会精确告诉你哪个用例挂了、期望值和实际值分别是什么。这个反馈闭环一旦建立起来，你对重构的信心会完全不一样。
4.2 用 MockK 测试带外部依赖的类
真实业务里，类很少是纯函数。假设有个OrderViewModel依赖OrderRepository去拉数据，我们要验证“加载成功时状态更新为 Success”：
class OrderViewModelTest { private val repository = mockk<OrderRepository>() private lateinit var viewModel: OrderViewModel @Before fun setUp() { viewModel = OrderViewModel(repository) } @Test fun `加载订单成功_状态应为Success`() = runTest { // Arrange：Mock 仓库返回固定数据 val fakeOrders = listOf(Order(id = 1, amount = 100)) coEvery { repository.fetchOrders() } returns fakeOrders // Act viewModel.loadOrders() // Assert assertThat(viewModel.state.value).isEqualTo(OrderState.Success(fakeOrders)) coVerify(exactly = 1) { repository.fetchOrders() } } @Test fun `加载订单失败_状态应为Error`() = runTest { coEvery { repository.fetchOrders() } throws IOException("网络异常") viewModel.loadOrders() assertThat(viewModel.state.value).isInstanceOf(OrderState.Error::class.java) } }这里有几个关键点：runTest来自协程测试库，它会自动处理挂起函数的调度；coEvery用于挂起函数的打桩；coVerify验证调用次数。如果你用的是StateFlow，断言时记得取.value，别直接比较 Flow 对象本身。
4.3 参数化测试：一个用例覆盖多组数据
当你要验证同一个逻辑在多组输入下的表现时，别复制粘贴一堆用例，用参数化测试更清爽。JUnit 4 的写法是@RunWith(Parameterized::class)，配合@Parameterized.Parameters提供数据源：
@RunWith(Parameterized::class) class DiscountParameterizedTest( private val input: Long, private val expected: Long ) { companion object { @JvmStatic @Parameterized.Parameters fun data(): List<Array<Any>> = listOf( arrayOf(99L, 99L), // 不满100，不打折 arrayOf(100L, 80L), // 满100减20 arrayOf(250L, 200L), // 满200减50 arrayOf(1000L, 800L) // 满800减200 ) } @Test fun `折扣计算_多组输入验证`() { assertThat(DiscountCalculator().calculate(input)).isEqualTo(expected) } }参数化测试的好处是失败信息会带上具体是哪组数据挂了，排查效率高。缺点是数据源和用例逻辑分离，读起来要来回跳，所以数据组数不多（比如三五组）时，我反而倾向于写多个独立用例，可读性更好。这个取舍看个人习惯。
4.4 覆盖率统计：数字要看，但别迷信
Android 项目统计单元测试覆盖率，主流方案是JaCoCo。在build.gradle里加插件配置，跑完测试后生成 HTML 报告，能看到每个类的行覆盖率和分支覆盖率。配置大概长这样：
plugins { id("jacoco") } jacoco { toolVersion = "0.8.11" } tasks.withType<Test> { configure<JacocoTaskExtension> { isIncludeNoLocationClasses = true excludes = listOf("jdk.internal.*") } }跑完./gradlew testDebugUnitTest jacocoTestReport，报告在build/reports/jacoco/下。关于覆盖率，我的态度是：看趋势不看绝对值。核心业务逻辑（金额、状态机、权限判断）争取 80% 以上，UI 层、框架胶水代码覆盖率低很正常，别为了数字去写一堆没有断言的“假测试”。覆盖率是手段不是目的，真正的目的是让你敢改代码。
5. 常见问题与排查技巧实录
5.1 高频报错速查表
下面这张表是我这些年攒下来的“血泪清单”，大部分新手卡住的问题都能在里面找到答案：
| 报错/现象 | 常见原因 | 解决思路 |
|---|---|---|
Method xxx not mocked | 本地测试调用了未 Mock 的 Android 框架方法 | 抽离框架依赖，或用 Robolectric，或 Mock 掉 |
No tests found | 测试类命名不符合规范或目录放错 | 类名以 Test 结尾，确认在src/test/下 |
Unresolved reference: mockk | 依赖配置到了错误的 configuration | 检查是否用了testImplementation |
| 协程测试卡住不结束 | 用了runBlocking且调度器未正确配置 | 改用runTest，注入TestDispatcher |
verify报调用次数不符 | 被测方法内部调用了多次，或参数不匹配 | 用exactly明确次数，match校验参数 |
| Robolectric 资源加载失败 | 版本与compileSdk不匹配 | 对齐版本，清理构建缓存重试 |
5.2 协程测试的调度器陷阱
这个坑值得单独拎出来说。测试协程代码时，如果被测类内部用了Dispatchers.IO或Dispatchers.Main，在本地 JVM 上Main调度器根本不存在，测试会直接崩。解决办法是把调度器作为依赖注入，测试时替换成TestDispatcher：
class OrderViewModel( private val repository: OrderRepository, private val dispatcher: CoroutineDispatcher = Dispatchers.IO ) : ViewModel() { fun loadOrders() { viewModelScope.launch(dispatcher) { // ... } } }测试里传UnconfinedTestDispatcher()进去，协程会同步执行，断言时机就好控制了。这个改造看起来多了一行构造参数，但它换来的是完全可控的测试环境，非常值。
5.3 测试之间的相互污染
单元测试理想状态下应该互相独立，但实际项目里经常出现“单独跑通过、一起跑失败”的情况。常见原因有三：静态变量/单例状态没重置、Mock 没在@After里清理、共享了可变的外部资源。排查方法很简单：先单独跑失败的用例，如果通过，那就是污染问题；再二分法注释掉其他用例，定位污染源。
预防手段：每个测试类在@Before里重建被测对象，@After里unmockkAll()或clearAllMocks()；单例类尽量改成可注入的实例；测试里别依赖系统时间，用固定的Clock或时间提供者。
5.4 老项目补测试的渐进策略
接手一个零测试的老项目，别想着一次性补齐，那不现实。我的做法是从改动最频繁的模块开始，每次改 bug 或加需求时，顺手给涉及的方法补上测试，这叫“童子军原则”——离开时比来时干净一点。优先补三类：核心算法、历史 bug 高发区、即将重构的模块。跑一段时间后你会发现，测试覆盖到的地方，改起来明显更踏实，团队也会慢慢形成习惯。
提示：补测试时如果发现某个方法根本没法测，别硬写，先做小步重构（抽方法、注入依赖），重构完测试自然就好写了。测试写不动是设计问题的信号，别用 Mock 硬糊。
6. 我个人的几条实操心得
最后聊几句掏心窝子的。第一，测试代码也是生产代码，同样要讲命名、讲结构、讲可维护性，别把它当二等公民，否则半年后你自己都不想看。第二，别追求 100% 覆盖率，那是个伪目标，投入产出比在 70% 之后急剧下降，把精力放在核心逻辑上更划算。第三，测试跑得慢就是原罪，本地单元测试整套跑完应该控制在几十秒内，超过这个数就要查查是不是混进了仪器测试或者有死循环。第四，CI 上一定要跑测试，本地靠自觉不靠谱，把./gradlew test挂到流水线上，红灯了就不许合代码，习惯是逼出来的。
这套东西我用了几年，最大的感受是：单元测试不是给领导看的 KPI，是给自己留的后路。哪天凌晨被叫起来修线上问题，你会感谢当初多写的那几个用例。
