2、测试环境搭建：添加测试依赖、配置测试运行器、创建第一个测试类

好，咱们正式开始动手了。

上一章聊了聊测试的价值和分类，说白了就是让你明白为什么要写测试。这一章，咱们直接进入实战——把测试环境搭起来。

我见过不少团队，测试方案设计得天花乱坠，结果一跑起来全是依赖冲突、运行器找不到、测试类报红。嗯，环境没搭好，后面全是白费功夫。

所以这一章，我会带你一步步把地基打牢。你跟着我走一遍，后面写测试就会特别顺畅。

2.1 添加测试依赖

在 Android 项目里加测试依赖，其实就两件事：加 build.gradle 里的配置，然后 Sync 一下。

我个人习惯把测试依赖分成三块：

• 单元测试依赖——跑在 JVM 上的，不需要设备
• UI 测试依赖——需要模拟器或真机
• Compose 专用依赖——专门给 Compose UI 测试用的

下面是我常用的一个版本组合，目前稳定好用：

// 项目级 build.gradle (Project)
buildscript {
    ext {
        compose_bom = '2024.02.00'
        junit_version = '1.10.2'
        espresso_version = '3.5.1'
    }
}

// 模块级 build.gradle (Module: app)
dependencies {
    // 单元测试
    testImplementation "junit:junit:4.13.2"
    testImplementation "org.jetbrains.kotlin:kotlin-test"

    // Android 单元测试（需要 Robolectric 或类似框架时）
    testImplementation "androidx.test:core-ktx:1.5.0"
    testImplementation "org.robolectric:robolectric:4.11.1"

    // UI 测试（Instrumented）
    androidTestImplementation "androidx.test:runner:1.5.2"
    androidTestImplementation "androidx.test:rules:1.5.0"
    androidTestImplementation "androidx.test.espresso:espresso-core:$espresso_version"

    // Compose UI 测试
    androidTestImplementation platform("androidx.compose:compose-bom:$compose_bom")
    androidTestImplementation "androidx.compose.ui:ui-test-junit4"
    debugImplementation "androidx.compose.ui:ui-test-manifest"
}

2.2 配置测试运行器

依赖加完了，下一步是告诉 Android 系统：嘿，我要跑测试了，你用哪个运行器？

默认情况下，Android Studio 会用 AndroidJUnitRunner。但如果你用的是 Compose，我建议你显式声明一下，避免某些诡异的问题。

在 build.gradle 的 defaultConfig 块里加上：

android {
    defaultConfig {
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        // 如果你用 Compose，可以加上这个（可选）
        testInstrumentationRunnerArguments = [
            'clearPackageData': 'true'
        ]
    }
}

为什么要加 clearPackageData？

我曾经遇到过一个问题：跑完一个测试后，应用残留数据影响了下一个测试的结果。加上这个参数，每次跑测试前会自动清理数据，保证测试隔离性。说白了，就是让每个测试都从「干净」的状态开始。

2.3 创建第一个测试类

环境搭好了，咱们来写第一个测试类。

先别急着写复杂的逻辑，咱们先跑通一个最简单的例子，验证环境是否正常。

2.3.1 单元测试示例

在 src/test/java/ 目录下创建一个测试类：

import org.junit.Test
import org.junit.Assert.*

class ExampleUnitTest {

    @Test
    fun addition_isCorrect() {
        assertEquals(4, 2 + 2)
    }

    @Test
    fun string_concatenation() {
        val result = "Hello, " + "World"
        assertEquals("Hello, World", result)
    }
}

右键点击类名，选择「Run ExampleUnitTest」。如果看到绿色勾，说明单元测试环境没问题。

2.3.2 Compose UI 测试示例

在 src/androidTest/java/ 目录下创建：

import androidx.compose.ui.test.junit4.createComposeRule
import androidx.compose.ui.test.onNodeWithText
import androidx.compose.ui.test.performClick
import org.junit.Rule
import org.junit.Test

class ExampleComposeTest {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun buttonClick_updatesText() {
        // 设置 Compose 内容
        composeTestRule.setContent {
            // 假设有一个简单的 Composable
            Greeting(name = "Android")
        }

        // 验证初始文本
        composeTestRule.onNodeWithText("Hello, Android!").assertExists()

        // 模拟点击
        composeTestRule.onNodeWithText("Click me").performClick()

        // 验证点击后的文本
        composeTestRule.onNodeWithText("Clicked!").assertExists()
    }
}

这里有个关键点：createComposeRule() 是 Compose 测试的核心。它会自动管理 Compose 的生命周期，你只需要设置内容，然后断言 UI 状态即可。

2.4 知识体系总览

下面这张图帮你理清本章的核心结构：

2.5 常见问题与避坑

环境搭建这块，我踩过的坑比写测试本身还多。分享几个典型的：

• 依赖冲突： 不同库引用了同一个库的不同版本。解决办法是用 configurations.all { resolutionStrategy { force '...' } } 强制统一版本。
• Compose 测试找不到节点： 检查是否加了 ui-test-manifest 依赖。没有它，Compose 测试跑不起来。
• 测试运行器报错： 确认 testInstrumentationRunner 拼写正确。我手滑写过 AndroidJunitRunner（小写 u），找了半小时 bug。

好了，环境搭好了，测试类也跑通了。下一章咱们会深入 Compose UI 测试的核心——如何定位 UI 元素、如何模拟交互、如何验证状态。你准备好了吗？

---