1. 测试夹具基础概念

1.1 什么是测试夹具

测试夹具（Test Fixture） 是指为执行测试而准备的固定环境与资源集合。在 Android 测试语境中，夹具涵盖了被测对象实例、依赖注入容器、数据库状态、文件系统快照、网络模拟端点以及配置参数等。夹具不是测试逻辑本身，而是让测试逻辑能够稳定、重复、独立运行的前提条件。

1.2 测试夹具的作用与价值

• 消除不确定性：固定时间、固定数据、固定依赖，使测试结果仅由被测代码决定。
• 提升执行速度：预置内存对象而非每次重新创建进程或启动 Activity。
• 隔离测试用例：每个用例拥有独立的夹具副本，不共享可变状态。
• 简化断言逻辑：夹具已知输入，输出只需比对预期值，无需处理环境噪声。
• 支持参数化：同一套夹具结构可注入不同数据组合，驱动大量边界用例。

1.3 测试夹具与测试代码的关系

测试夹具和测试代码是“准备 — 执行 — 验证 — 拆卸”四阶段中的前、后两段。夹具负责第 1 和第 4 阶段，测试代码负责第 2、3 阶段。两者通过依赖注入或回调接口连接，不应互相耦合。

// 测试夹具与测试代码分离的典型结构
class UserRepositoryTest {
    // —— 夹具开始 ——
    private lateinit var database: AppDatabase
    private lateinit var api: MockWebServer

    @Before
    fun setUp() {
        database = Room.inMemoryDatabaseBuilder(
            InstrumentationRegistry.getInstrumentation().targetContext,
            AppDatabase::class.java
        ).build()
        api = MockWebServer()
        api.start()
    }

    @After
    fun tearDown() {
        database.close()
        api.shutdown()
    }
    // —— 夹具结束 ——

    // —— 测试代码 ——
    @Test
    fun testSaveUser() {
        val user = User(id = 1, name = "Alice")
        database.userDao().insert(user)
        val loaded = database.userDao().getById(1)
        assertEquals("Alice", loaded.name)
    }
}

1.4 Android 测试层次中的夹具定位

Android 测试从上到下分为 UI 测试、集成测试、单元测试 三个层次。不同层次的夹具复杂度和作用域差异很大：

• 单元测试：夹具最小，通常只包含一个类实例 + Mock 依赖。运行在 JVM 上，不依赖真机或模拟器。
• 集成测试：夹具涉及真实数据库、文件系统或网络端点。运行在 Android 设备或模拟器上，使用 AndroidJUnitRunner。
• UI 测试：夹具需要启动 Activity、注入 Intent、配置系统权限。常借助 ActivityScenario 和 ComposeTestRule。

1.5 Android 测试夹具的典型实现模式

在实际项目中，夹具设计有三种主流实现模式，开发者应根据测试层次和团队规范选择：

// Factory/Build Pattern 示例：ObjectMother 风格
object TestUsers {
    fun alice() = User(
        id = 1,
        name = "Alice",
        email = "alice@example.com",
        role = Role.ADMIN
    )

    fun bob() = User(
        id = 2,
        name = "Bob",
        email = "bob@example.com",
        role = Role.GUEST
    )

    fun listOfThree() = listOf(alice(), bob(), User(
        id = 3,
        name = "Charlie",
        email = "charlie@example.com",
        role = Role.EDITOR
    ))
}

1.6 常见错误与稳定性优化

• 错误：全局静态状态泄漏 — 多个测试共享一个静态 DatabaseHelper 实例，导致数据污染。应使用 inMemoryDatabaseBuilder 每次重新创建。
• 错误：Fixture 与测试逻辑混合 — 在断言语句中创建文件或网络连接。必须通过 @Before / @After 分离。
• 错误：忽略 TearDown 异常 — 夹具拆卸中抛异常会掩盖测试失败。使用 @Rule 或 Closeable 接口确保资源释放。

// 使用 @Rule 安全管理夹具资源的推荐写法
@RunWith(AndroidJUnit4::class)
class SafeFixtureTest {
    @get:Rule
    val mockServerRule = MockWebServerRule() // 自动 shutdown

    @get:Rule
    val databaseRule = InMemoryDatabaseRule() // 自动 close

    @Test
    fun testWithSafeFixture() {
        // 直接使用 databaseRule.database 和 mockServerRule.server
        // 无需手动 setUp / tearDown
    }
}

1.7 本章要点总结