第1章 分离动机与价值

将 ViewModel 与 UI 夹具（Activity / Fragment / View）耦合在一起，是移动端测试脆性的主要根源。本章从测试维护痛点出发，揭示耦合导致的脆性本质，并量化分离后的可测试性收益。

1.1 测试维护痛点

Android 原生开发中，常见的耦合模式是 ViewModel 直接持有 Context、View 引用或 LiveData 绑定在 Activity 生命周期内。这种模式导致以下测试问题：

1.2 UI 与 ViewModel 耦合导致的脆性

耦合不是简单的代码组织问题，而是一组结构性脆性因素的集合：

• 生命周期绑定： ViewModel 的 onCleared() 与 UI 的销毁配对，测试中难以验证 ViewModel 自身状态。
• 隐式依赖链： ViewModel 通过 SavedStateHandle 访问 Bundle，单元测试必须提供 Bundle 和 Application 上下文。
• UI 线程敏感： LiveData.setValue() 只能在主线程调用，导致普通单元测试框架（如 JUnit）无法直接测试。
• 重构阻力： 修改 ViewModel 定义时，UI 夹具的 observe 代码也需要同步修改，增加回归成本。

1.3 分离后的可测试性收益

当 ViewModel 不再依赖 Context、View 和 LiveData（改用 StateFlow 配合协程），UI 夹具只负责订阅和渲染时，测试体系发生质变：

分离后的典型测试结构如下（仅作示意，不需完整运行）：

// ViewModel 不再继承任何 Android 类
data class MainUiState(val items: List<Item>, val isLoading: Boolean)

class MainViewModel(
    private val repository: ItemRepository
) {
    private val _state = MutableStateFlow(MainUiState())
    val state: StateFlow<MainUiState> = _state.asStateFlow()

    fun loadItems() {
        viewModelScope.launch {
            _state.update { it.copy(isLoading = true) }
            val items = repository.fetchItems()
            _state.update { it.copy(items = items, isLoading = false) }
        }
    }
}

// 单元测试直接构造 ViewModel，注入 FakeRepository
class MainViewModelTest {
    private val fakeRepo = FakeItemRepository()
    private val viewModel = MainViewModel(fakeRepo)

    @Test
    fun `loadItems changes state to loading then loaded`() = runTest {
        val result = viewModel.state.toList()
        assertEquals(result[0].isLoading, false)
        viewModel.loadItems()
        assertEquals(result[1].isLoading, true)
        assertEquals(result[2].items.size, 3)
    }
}